WAF und Injektionsschutz

1) Warum WAF im API-Zeitalter

• „long tail“ -Integrationen (Erbcode, Affiliate-Webhooks),
• Parsing-Diskrepanzen (Proxy ↔ Framework),
• neue Protokoll-/Verschleierungstechniken der Umgehung.
• WAF gibt die Grenze des frühen Versagens (early deny) und des „virtuellen Patchens“ vor der Veröffentlichung des Codes vor, ersetzt aber nicht die sichere Entwicklung.

2) Bedrohungsmodell: Arten von Injektionen für API

SQLi/ORMi: classic/boolean/time-based/stacked; blind durch Verzögerungen.
NoSQLi (Mongo/Elastic): Operatoren'$ ne/$ gt', JSON-Injektion, Regex-DoS.
Command Injection/RCE: Shell-Metazeichen, Ersetzen von Argumenten, unsafe deserialization → code exec.
XXE: externe Entitäten/DTDs in XML.
SSRF: Zugang zu '169. 254. 169. 254 '/interne Dienste; DNS-rebinding.
Template Injection: Jinja/Thymeleaf/Handlebars; `{{77}}`.
LDAP/EL Injection, XPath, Header injection (CRLF), Path traversal.
GraphQL-spezifisch: '__ schema' introspection, Tiefe/Komplexität der Abfragen.
JSON/JS-spezifisch: Prototype Pollution ('__ proto __', 'constructor').
gRPC/Protobuf: oversized messages, field smuggling through mismatch schemas.

3) WAF-Architekturen

CDN-WAF Perimeter: schnelle Geo/ASN-Filterung, grundlegende Bot-Steuerung, Cache/Anti-Padding.
L7 Perimeter (NGINX/Envoy/APISIX/Kong): präzises Parsen, tiefe Regeln, Integration mit PDP/Limits.
Sidecar/mash (Envoy WASM/Filter): Per-Service, nah an den Daten, weniger falsch-positiv für interne APIs.
Empfehlung: Zweischichtmodell (CDN-WAF + L7 WAF).

4) Parsing, Normalisierung und Anti-Bypass

• Pfad-Normalisierung ('/a/% 2e% 2e/b '→ Fehler),' UTF-8 '/Unicode confusables, NUL-Bytes.
• Einzeldecodierung: URL-/HTML-/Unicode-/Base64-Schichten, Verbot der Doppeldecodierung.
• Einschränkungen: 'max _ headers', 'max _ header _ size', 'max _ body _ size', 'max _ args', JSON-Tiefe, multipart parts limit, Verbot von 2x gzip/zip bombs.
• Content-Type-Richtlinien: 'application/json' nur auf JSON-Endpoints; "polyglot' abzulehnen.

5) Regelmodelle

Negativ (Signaturen): OWASP CRS (SQLi/XSS/SSRF/Java/Node RCE usw.). Schneller Start.
Positiv (allow-list): strenge Schemata (JSON Schema/Protobuf), Typen und Bereiche; entlang der Routen.
Abnormal/Scoring: Summierung von „verdächtigen“ Zeichen → Blockierungsschwelle.
Kontextuell: unterschiedliche Profile für „POST/Zahlungen“ und „GET/Status“; kleiner als FP.

6) Schutzblöcke (gebündelt)

1. Schemata und Typen: JSON Schema/Protobuf Validierung zur Geschäftslogik.
2. Parametrisierung: vorbereitete Ausdrücke, ORM-Verbindungen, Verbot der Verkettung.
3. Ausgabe-Escaping: HTML/JS/SQL im Kontext.
4. Körperrichtlinien: Inhaltstyp, Größe, Multipart-Beschränkungen, Verbot von Binaries auf JSON-Stiften.
5. WAF-Regeln: CRS + angepasst negativ/positiv.
6. Rate/Quota/Concurrency: Unterdrückung von Brute/Turtle DDoS, Protective Captchas/Challenges für öffentliche Formen.
7. Isolierung von Netzwerken: egress-Richtlinien für SSRF (deny RFC1918/metadata/Unix sockets).
8. Headers-Hygiene: „X-Content-Type-Options: nosniff“, „Content-Security-Policy“ für die Front, „Referrer-Policy“.
9. GraphQL guard: Tiefen-/Schwierigkeitsgrenzen, Verbot der Introspektion in der Produktion (oder Rolle-Gate).

7) Beispiele für Konfigurationen

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: Typenbeschränkung und Anti-Verschleierung

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) Tuning und Reduzierung von False Positives (FP)

Per-Route-Profile: Strenge Regeln nur dort, wo sie angemessen sind (z.B. '/search 'erlaubt '/'%').
Shadow/Report-Only: Protokollierung der Betätigungen vor dem Block; A/B Vergleich der Metriken.
Benutzerdefinierte Allow-Listen für „laute“ legitime Parameter.
Scoring: Blocken nur, wenn die Summe der Indikatoren> Schwelle ist.
Experimente: ein kleiner Prozentsatz des Verkehrs auf die neuen Regeln → Auto-Rollback.

9) Beobachtbarkeit und Forensik

Метрики: `waf_block_total{rule}`, `waf_anomaly_score`, `request_body_rejected_total`, `schema_violation_total`, `ssrf_block_total`.
Protokolle (gesampelt): Regel, Teil der Abfrage (bearbeitet), 'trace _ id', 'tenant', 'route', Grund. Maskieren Sie PII/Geheimnisse.
Dashboards: Top-Regeln/Pfade, FP-Cluster, Post-Release-Dynamik.
Incidents: Erhaltung von Artefakten (payload, pcap, falls erforderlich), RCA-Produkten und „virtuellen Patches“.

10) Test- und Chaos-Szenarien

WAF-Bypass-Gehäuse (SQLi/XSS/SSRF), Doppel-/Dreifachkodierung, Unicode-Mix.
Parsing-Unterschiede: Senden Sie payload, wo der Proxy und das Framework auseinander gehen können (Parameter-Takes, Arrays,'; 'vs' &').
Slow-POST/Oversize, Zip-Bomben, mehrteilige Formen, fehlgeleitete Boundary.
GraphQL: Tiefen-/Komplexitätsgenerator, Überprüfung von Limits und Timeouts.

11) Antipatterns

„CRS eingeschaltet und vergessen“: keine Schaltungen, kein Tuning entlang der Strecken.
Protokolle mit rohem Anforderungskörper und PII.
Keine Normalisierung/Größenbegrenzung → Bypässe, DoS auf Parsing.
Auslassen von 'Content-Type '/charset-Prüfungen → polyglotte Angriffe.
Das Fehlen von Egress-Filtern → SSRF zu Cloud-Metadaten.
Ein gemeinsames Profil für externe und interne APIs.
Unkontrollierte Ausnahmen „für den Partner“ → Löcher im Perimeter.

12) Spezifität von iGaming/Finanzen

Verstärkte Profile auf Zahlungs-/Lead-Pens: kleine Body-Limits, strenge Schemata, Deny-Listen für Account/IBAN/PAN-Felder (Maskierung, Formatprüfungen).
Webhooks von PSP/KYC: HMAC-Signatur/mutuales TLS, separate WAF-Profile, Anti-Replay.
Geo/ASN-Filter und Verhaltensgrenzen, um Bot-Registrierungen und Bonus-Missbrauch zu verhindern.
Ereignisprotokolle unveränderlich (Audit), Lagerung nach Jurisdiktionen.

13) Checkliste Prod-Ready

• Zweischichtige WAF (CDN + L7), einheitliche Normalisierung und Größengrenzen.
• OWASP CRS aktiviert, benutzerdefinierte Regeln pro Route; JSON Schema/Protobuf auf Schreibstiften.
• Content-Type/charset-Richtlinien; Verbot der doppelten Dekodierung/NULL/traversal.
• SSRF-egress-Block für private Bereiche/Metadaten; DNS-Rebinding-Schutz.
• Rate/Quota/Concurrency und Anti-Bot (Herausforderungen) auf öffentlichen Formularen.
• Shadow/Report-Only → canary → enforce; Auto-Rollback durch SLO und FP.
• Metriken/Logs/Traces mit Maskierung; dashboards „top rules “/FP.
• Virtuelle Patch-Playbooks und RCAs; regelmäßige Tests der Umwege.
• Separate Profile für PSP/KYC-Webhooks, Zahlungsschreiber und interne APIs.

14) TL; DR

Erstellen Sie Schutz nach Schichten: Normalisierung und Grenzen → Schemata/Typen → Parametrierung → WAF (CRS + custom) → Rate/Bot-Filter → SSRF-Egress-Block. Tune per-Route, starten Sie neue Regeln in shadow → canary, achten Sie auf Metriken/FPs und machen Sie „virtuelle Patches“ vor dem Code-Fix. Für Zahlungs-/Webhook-Pfade gibt es separate strenge Profile, HMAC/mTLS und minimale Vertrauensfenster.