WAF e proteção contra injeções

1) Porquê o WAF na época da API

• «colas longas» das integrações (código de herança, webhooks associados),
• divergências de parsing (proxy ↔ quadro),
• novas técnicas de varredura protocolares/supressores.
• WAF dá limite de falha precoce (early deny) e «patching virtual» antes do lançamento do código, mas não substitui o desenvolvimento seguro.

2) Modelo de ameaça: tipos de injeções para API

SQLi/ORMi: classic/boolean/time-based/stacked; blind através de atrasos.
NoSQLi (Mongo/Elastic): operadores de '$ ne/$ gt', JSON inhation, regex-DoS.
Command Inhation/RCE: shell-metacarbonetos, troca de argumentos, unsafe deserialização → código exec.
XXE: Entidades externas/DTD em URL.
SSRF: acesso a '169. 254. 169. 254 '/serviços internos; DNS-rebinding.
Template Injection: Jinja/Thymeleaf/Handlebars; `{{77}}`.
LDAP/EL Injection, XPath, Header injection (CRLF), Path traversal.
O gráfico QL é específico: '__ schema' introspecção, profundidade/complexidade das solicitações.
JSON/JS específico: Prototype Pollute ('__ proto __', 'construtor').
gRPC/Protobuf: mensagens oversized, field smuggling através da discrepância de esquemas.

3) Arquiteturas WAF

Perímetro CDN-WAF: filtragem geo/ASN rápida, controle bot básico, dinheiro/antipadding.
Perímetro L7 (NGINX/Envoy/APISIX/Kong): parsing exato, regras profundas, integração com PDP/limites.
Saidcar/mash (Envoy WASM/Filter): serviço para-dados próximo, menos falso positivo para API interna.
Recomendação: modelo de duas camadas (CDN-WAF + L7 WAF).

4) Parsing, normalização e anti-contorno

• Normalização de caminhos ('/a/% 2e% 2e/b '→ falha),' UTF-8 '/Unicode confusíveis, bytes NUL.
• Decodificação unificada: URL-/HTML-/Unicode-/Base64 camadas, proibição de decodificação dupla.
• Restrições: 'max _ headers', 'max _ header _ size', 'max _ body _ size', 'max _ args', profundidade JSON, limite de partes multipart, proibição de 2x gzip/zip-bombas.
• Políticas de Conteúdo: 'aplicação/json' apenas em endpoentes JSON; rejeitar «polyglot».

5) Modelos de regras

(assinaturas): OWASP CRS (SQLI/XSS/SSRF/Java/Node RCE etc.). Partida rápida.
Positivo (allow-list): esquemas rigorosos (JSON Schema/Protobuf), tipos e faixas; pelo caminho.
Anormal/anistia, somando sinais «suspeitos» → limiar de bloqueio.
Contexto: perfis diferentes para 'POST/payments' e 'GET/status'; menos FP.

6) Blocos de bloqueio (no laço)

1. Esquemas e tipos: JSON Schema/Protobuf validação para lógica de negócios.
2. Configuração: expressões preparadas, bindings de ORE, proibição de concatenação.
3. Output-escaping: HTML/JS/SQL contextualmente.
4. Políticas corporais: Conteúdo-Tipo, tamanho, limitações multipart, proibição de binários em canetas JSON.
5. Regras WAF: CRS + castoma negativo/positivo.
6. Rate/Cota/Concurrency: supressão de DDoS brute/tartaruga, capches de proteção/challengs para formas públicas.
7. Isolamento de redes: Políticas egress para SSRF (deny RFC1918/metadata/Unix sockets).
8. Headers-Higiene: 'X-Conteúdo-Tipos-Opções', 'Conteúdo-Segurança-Policy' para frente, 'Referrer-Policy'.
9. guard: limites de profundidade/complexidade, proibição de introspation na venda (ou rol-gate).

7) Exemplos de configuração

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: limitação de tipos e anti-engajamento

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) Sintonizar e reduzir falsos efeitos (FP)

Perfis per-road: regras rigorosas apenas quando apropriadas (por exemplo, '/search 'permite '/'%').
Shadow/Report-Only: Logando o trabalho em frente ao bloco; A/B compara métricas.
Listas de alow customizadas para parâmetros legítimos «ruidosos».
Mapeamento: bloquear somente com a soma dos indicadores> limiar.
Experimentos: uma pequena porcentagem de tráfego para as novas regras → auto-rollback.

9) Observabilidade e forensica

Метрики: `waf_block_total{rule}`, `waf_anomaly_score`, `request_body_rejected_total`, `schema_violation_total`, `ssrf_block_total`.
Logs (samplicados): regra, parte da consulta (editada), «trace _ id», «tenant», «road», razão. Disfarce PII/segredos.
Dashboards: regras/caminhos top, cluster FP, dinâmica após o lançamento.
Incidentes: preservação de artefatos (payload, pcap, se necessário), produtos RCA e «patches virtuais».

10) Testes e cenários de caos

Caixas de rondas WAF (SQLI/XSS/SSRF), codificações duplas/triplas misturadas pelo Unicode.
Diferenças de parsing: envie payload, onde o proxy e o quadro podem divergir (duplicações, matrizes, ';' vs '&').
Slow-POST/oversize, bombas zip, formas múltiplas, boundary erradas.
GraphQL: gerador de profundidade/complexidade, verificação de limites e temporizadores.

11) Antipattern

«Ativando o CRS e esquecendo», sem circuitos, sem sintonização sobre trilhos.
Logs com corpo cru de consulta e PII.
Não há normalização/limite de tamanho → rondas DoS para parsing.
Omissão do 'Conteúdo-Tipo '/charset de verificação → poliglota.
Não há filtros egress → SSRF para o metadado da nuvem.
Um perfil compartilhado para APIs externas e internas.
Exceções descontroladas para o parceiro → buracos no perímetro.

12) Especificidades do iGaming/Finanças

Os perfis reforçados nas canetas de pagamento/saída são pequenos limites body, esquemas rigorosos, listagens deny para conta/BAN/PAN (camuflagem, verificações em formato).
Webhooks PSP/KYC: assinatura HMAC/TLS mutual, perfis WAF individuais, anti-replay.
Filtros geo/ASN e limites comportamentais para evitar registros de bot e bónus.
Os registros de incidentes são imutáveis (auditoria), armazenamento por jurisdição.

13) Folha de cheque pró-prontidão

• WAF de duas camadas (CDN + L7), normalização unificada e limites de tamanho.
• O OWASP CRS está incluído, regras custômicas para-rota; JSON Schema/Protobuf em canetas write.
• Políticas de Conteúdo-Tipo/charset; proibição de decodificação dupla/NULL/traversal.
• unidade SSRF-egress para faixas privadas/metadata; Proteção DNS-rebinding.
• Rate/Quota/Concurrency e anti-bot em formas públicas.
• Shadow/Report-Only → canary → enforce; auto-rollback por SLO e FP.
• Métricas/logs/trens mascarados; dashboards «top regras »/FP.
• Playbooks de patch virtual e RCA; testes regulares de rondas.
• Perfis individuais para webhooks PSP/KYC, canetas de pagamento e API interna.

14) TL; DR

Construa a proteção em camadas: normalização e limites de → de padrão/tipo → configuração de → WAF (CRS + casta) → rate/bot-filtros → egress SSRF. Tuneia por-rota, execute novas regras em shadow → canary, siga as métricas/FP e faça «patches virtuais» até o código do código. Para caminhos de pagamento/webhook - perfis rígidos individuais, HMAC/mTLS e janelas mínimas de confiança.