WAF и защита от инъекций

1) Зачем WAF в эпоху API

• «длинных хвостов» интеграций (наследный код, партнерские вебхуки),
• расхождений парсинга (прокси ↔ фреймворк),
• новых протокольных/обфускационных техник обхода.
• WAF дает рубеж раннего отказа (early deny) и «виртуальный патчинг» до релиза кода, но не заменяет безопасную разработку.

2) Модель угроз: виды инъекций для API

SQLi/ORMi: classic/boolean/time-based/stacked; blind через задержки.
NoSQLi (Mongo/Elastic): операторы `$ne/$gt`, JSON injection, regex-DoS.
Command Injection / RCE: shell-метасимволы, подмена аргументов, unsafe deserialization → code exec.
XXE: внешние сущности/DTD в XML.
SSRF: доступ к `169.254.169.254`/внутренним сервисам; DNS-rebinding.
Template Injection: Jinja/Thymeleaf/Handlebars; `{{77}}`.
LDAP/EL Injection, XPath, Header injection (CRLF), Path traversal.
GraphQL-специфично: `__schema` introspection, глубина/сложность запросов.
JSON/JS-специфично: Prototype Pollution (`__proto__`, `constructor`).
gRPC/Protobuf: oversized messages, field smuggling через несовпадение схем.

3) Архитектуры WAF

Периметр CDN-WAF: быстрое geo/ASN-фильтрование, базовый бот-контроль, кэш/антипаддинг.
Периметр L7 (NGINX/Envoy/APISIX/Kong): точный парсинг, глубокие правила, интеграция с PDP/лимитами.
Сайдкар/мэш (Envoy WASM/Filter): пер-сервис, близко к данным, меньше ложно-положительных для внутренних API.
Рекомендация: двухслойная модель (CDN-WAF + L7 WAF).

4) Парсинг, нормализация и анти-обход

• Нормализация путей (`/a/%2e%2e/b` → отказ), `UTF-8`/Unicode confusables, NUL-байты.
• Единый декодинг: URL-/HTML-/Unicode-/Base64-слои, запрет двойного декодинга.
• Ограничения: `max_headers`, `max_header_size`, `max_body_size`, `max_args`, глубина JSON, лимит multipart-частей, запрет 2x gzip/zip-бомб.
• Политики Content-Type: `application/json` только на JSON-эндпоинтах; отклонять «polyglot».

5) Модели правил

Негативная (подписи): OWASP CRS (SQLi/XSS/SSRF/Java/Node RCE и др.). Быстрый старт.
Позитивная (allow-list): строгие схемы (JSON Schema/Protobuf), типы и диапазоны; по маршрутам.
Аномальная/скоринговая: суммирование «подозрительных» признаков → порог блокировки.
Контекстная: разные профили для `POST /payments` и `GET /status`; меньше FP.

6) Блоки защит (в связке)

1. Схемы и типы: JSON Schema/Protobuf валидация до бизнес-логики.
2. Параметризация: подготовленные выражения, ORM-биндинги, запрет конкатенации.
3. Output-escaping: HTML/JS/SQL контекстно.
4. Политики тела: Content-Type, размер, multipart-ограничения, запрет бинарей на JSON-ручках.
5. WAF-правила: CRS + кастомные негативные/позитивные.
6. Rate/Quota/Concurrency: подавление brute/черепашьей DDoS, защитные капчи/челленджи для публичных форм.
7. Изоляция сетей: egress-политики для SSRF (deny RFC1918/metadata/Unix sockets).
8. Headers-гигиена: `X-Content-Type-Options: nosniff`, `Content-Security-Policy` для фронта, `Referrer-Policy`.
9. GraphQL guard: лимиты глубины/сложности, запрет introspection в проде (или роль-гейт).

7) Примеры конфигураций

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: ограничение типов и анти-обфускация

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) Тюнинг и снижение ложных срабатываний (FP)

Профили per-route: строгие правила только там, где они уместны (например, `/search` допускает ``/`%`).
Shadow/Report-Only: логируем срабатывания перед блоком; A/B сравнение метрик.
Кастомные allow-списки для «шумных» легитимных параметров.
Скоринг: блокировать только при сумме индикаторов > порога.
Эксперименты: маленький процент трафика на новые правила → авто-rollback.

9) Наблюдаемость и форензика

Метрики: `waf_block_total{rule}`, `waf_anomaly_score`, `request_body_rejected_total`, `schema_violation_total`, `ssrf_block_total`.
Логи (сэмплированные): правило, часть запроса (редактированная), `trace_id`, `tenant`, `route`, причина. Маскируйте PII/секреты.
Дашборды: топ-правила/пути, FP-кластера, динамика после релиза.
Инциденты: сохранение артефактов (payload, pcap при необходимости), продуктов RCA и «виртуальных патчей».

10) Тестирование и хаос-сценарии

Корпуса обходов WAF (SQLi/XSS/SSRF), двойные/тройные кодировки, смешанные Unicode.
Различия парсинга: отправляйте payload, где прокси и фреймворк могут расходиться (дубли параметров, массивы, `;` vs `&`).
Slow-POST/oversize, zip-бомбы, многочастные формы, ошибочные boundary.
GraphQL: генератор глубины/сложности, проверка лимитов и таймаутов.

11) Антипаттерны

«Включили CRS и забыли»: без схем, без тюнинга по маршрутам.
Логи с сырым телом запроса и PII.
Нет нормализации/лимитов размеров → обходы, DoS на парсинг.
Пропуск `Content-Type`/charset проверок → полиглот-атаки.
Отсутствие egress-фильтров → SSRF к метадате облака.
Один общий профиль для внешних и внутренних API.
Бесконтрольные исключения «для партнера» → дыры в периметре.

12) Специфика iGaming/финансов

Усиленные профили на платежных/выводных ручках: маленькие body-лимиты, строгие схемы, deny-списки для account/IBAN/PAN-полей (маскирование, форматные проверки).
Вебхуки от PSP/KYC: HMAC-подпись/мутуальное TLS, отдельные профили WAF, анти-replay.
Гео/ASN-фильтры и поведенческие лимиты для предотвращения бот-регистраций и бонус-абьюза.
Журналы инцидентов неизменяемые (аудит), хранение по юрисдикциям.

13) Чек-лист prod-готовности

• Двухслойный WAF (CDN + L7), единая нормализация и лимиты размеров.
• OWASP CRS включен, кастомные правила per-route; JSON Schema/Protobuf на write-ручках.
• Политики Content-Type/charset; запрет двойного декодинга/NULL/ traversal.
• SSRF-egrеss-блок на приватные диапазоны/metadata; DNS-rebinding защита.
• Rate/Quota/Concurrency и анти-бот (челленджи) на публичных формах.
• Shadow/Report-Only → canary → enforce; авто-rollback по SLO и FP.
• Метрики/логи/трейсы с маскированием; дашборды «топ-правил»/FP.
• Плейбуки виртуального патча и RCA; регулярные тесты обходов.
• Отдельные профили для PSP/KYC вебхуков, платежных ручек и внутренних API.

14) TL;DR

Стройте защиту по слоям: нормализация и лимиты → схемы/типы → параметризация → WAF (CRS + кастом) → rate/бот-фильтры → egress-блок SSRF. Тюньте per-route, запускайте новые правила в shadow → canary, следите за метриками/FP и делайте «виртуальные патчи» до фикса кода. Для платежных/вебхук-путей — отдельные строгие профили, HMAC/mTLS и минимальные окна доверия.