GH GambleHub

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) Парсинг, нормалізація і анти-обхід

WAF повинен бачити те ж канонічне уявлення, що і додаток:
  • Нормалізація шляхів ('/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-egress-блок на приватні діапазони/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 і мінімальні вікна довіри.

Contact

Зв’яжіться з нами

Звертайтеся з будь-яких питань або за підтримкою.Ми завжди готові допомогти!

Розпочати інтеграцію

Email — обов’язковий. Telegram або WhatsApp — за бажанням.

Ваше ім’я необов’язково
Email необов’язково
Тема необов’язково
Повідомлення необов’язково
Telegram необов’язково
@
Якщо ви вкажете Telegram — ми відповімо й там, додатково до Email.
WhatsApp необов’язково
Формат: +код країни та номер (наприклад, +380XXXXXXXXX).

Натискаючи кнопку, ви погоджуєтесь на обробку даних.