WAF და ინექციებისგან დაცვა

1) რატომ არის WAF API ეპოქაში

• ინტეგრაციის „გრძელი კუდები“ (გვირგვინი კოდი, პარტნიორობა webhooks),
• პარსინგის განსხვავებები (მარიონეტული ჩარჩო),
• ახალი პროტოკოლი/შემოვლითი ტექნიკა.
• WAF იძლევა ადრეული უკმარისობის ხაზს (early deny) და „ვირტუალურ პატჩინგს“ კოდის გამოშვებამდე, მაგრამ არ ცვლის უსაფრთხო განვითარებას.

2) საფრთხის მოდელი: ინექციების ტიპები API- სთვის

SQLi/ORMi: classic/boolean/time-based/stacked; ბლინდი შეფერხებების საშუალებით.
NOSQLI (Mongo/Elastic): ოპერატორები 'ne/$ gt', JSON injection, regex-DoS.
Command Injection/RCE: shell-metasimwalls, არგუმენტების შეცვლა, 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 სპეციფიკურია: პროტოტიპი პოლიცია ('_ _ proto _ _', 'constructor').
GRPC/Protobuf: oversized messages, ველი smuggling სქემების შეუსაბამობის გზით.

3) WAF არქიტექტურა

CDN-WAF პერიმეტრი: სწრაფი geo/ASN ფილტრაცია, ძირითადი ბოტი კონტროლი, ქეში/ანტიპადინგი.
პერიმეტრი L7 (NGINX/Envoy/APISIX/Kong): ზუსტი პარსინგი, ღრმა წესები, ინტეგრაცია PDP/ლიმიტებთან.
Sidkar/Mesh (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 სიღრმე, მრავალჯერადი ნაწილების ლიმიტი, 2x gzip/zip ბომბების აკრძალვა.
• შინაარსის ტიპის პოლიტიკოსები: 'განაცხადი/json' მხოლოდ JSON endpoints; გადახრა „პოლიგლოტი“.

5) წესების მოდელები

უარყოფითი (ხელმოწერები): OWASP CRS (SQLI/XSS/SSRF/Java/Node RCE და ა.შ.). სწრაფი დასაწყისი.
პოზიტიური (ალოუ-სია): მკაცრი სქემები (JSON Schema/Protobuf), ტიპები და დიაპაზონი; მარშრუტების გასწვრივ.
არანორმალური/სკორინგი: „საეჭვო“ ნიშნების შეჯამება - დაბლოკვის ბარიერი.
კონტექსტური: სხვადასხვა პროფილები 'POST/payments' და 'GET/status'; ნაკლები FP.

6) დაცვის ბლოკები (თაიგულში)

1. სქემები და ტიპები: JSON Schema/Protobuf შესაბამისობა ბიზნეს ლოგიკამდე.
2. პარამეტრიზაცია: მომზადებული გამონათქვამები, ORM ბინდი, კონკატენაციის აკრძალვა.
3. Output-escaping: HTML/JS/SQL კონტექსტურად.
4. სხეულის პოლიტიკოსები: შინაარსის ტიპი, ზომა, მრავალფუნქციური შეზღუდვები, JSON სახელურებზე ორობების აკრძალვა.
5. WAF წესები: CRS + კასტომიური უარყოფითი/პოზიტიური.
6. Rate/Quta/Concurrency: brute/Currence DDoS- ის ჩახშობა, დამცავი ხაფანგები/ჩელენჯები საზოგადოებრივი ფორმებისთვის.
7. ქსელის იზოლაცია: egress პოლიტიკა SSRF- სთვის (დენის RFC1918/metadata/Unix sockets).
8. Headers ჰიგიენა: 'X-Content-Type-Options: nosniff', 'Content-Security-Policy' წინა, 'Referrer-Policy'.
9. GraphQL guard: სიღრმის/სირთულის შეზღუდვები, გაყიდვების აკრძალვა გაყიდვაში (ან როლი).

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
Connect CRS
Include /etc/modsecurity/crs/crs-setup. conf
Include /etc/modsecurity/crs/rules/.conf

Positive rules: JSON only and size limit
SecRule REQUEST_HEADERS:Content-Type "!@rx ^application/json($;)" "id:10001,phase:1,deny,status:415,msg:'Only JSON allowed'"
SecRequestBodyLimit 1048576
SecRequestBodyNoFilesLimit 1048576

Local Address Block (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) Tuning და ყალბი ოპერაციების შემცირება (FP)

პროფილები per-route: მკაცრი წესები მხოლოდ იქ, სადაც ისინი შესაფერისია (მაგალითად, '/search 'იძლევა "/'%').
Shadow/Report-Only: ბლოკის წინ მოქმედების ლოგიკა; A/B მეტრული შედარება.
Castomy allow სიები „ხმაურიანი“ ლეგიტიმური პარამეტრებისთვის.
სკორინგი: დაბლოკეთ მხოლოდ ინდიკატორების ჯამი> ბარიერი.
ექსპერიმენტები: ტრეფიკის მცირე პროცენტი ახალი წესებისთვის - ავტო-როლბაკი.

9) დაკვირვება და წინსვლა

Метрики: `waf_block_total{rule}`, `waf_anomaly_score`, `request_body_rejected_total`, `schema_violation_total`, `ssrf_block_total`.
Logs (მოდულირებული): წესი, მოთხოვნის ნაწილი (რედაქტირებული), 'trace _ id', 'tenant', 'route', მიზეზი. შენიღბეთ PII/საიდუმლოებები.
დაშბორდები: ტოპ წესები/ბილიკები, FP კლასტერები, დინამიკა გამოშვების შემდეგ.
ინციდენტები: არტეფაქტების შენარჩუნება (საჭიროების შემთხვევაში payload, pcap), RCA პროდუქტები და „ვირტუალური პატჩი“.

10) ტესტირება და ქაოსის სცენარები

WAF შემოვლითი შემთხვევები (SQLi/XSS/SSRF), ორმაგი/სამმაგი კოდირება, Unicode შერეული.
პარსინგის განსხვავებები: გაგზავნეთ payload, სადაც მარიონეტული და ჩარჩო შეიძლება განსხვავდებოდეს (პარამეტრების დუბლირება, მასივები, ';' vs '&').
Slow-POST/oversize, zip ბომბები, მრავალმხრივი ფორმები, მცდარი ბუნდოვანი.
GraphQL: სიღრმის/სირთულის გენერატორი, ლიმიტების და ტაიმაუტების შემოწმება.

11) ანტიპატერები

„მათ ჩართეს CRS და დაივიწყეს“: სქემების გარეშე, მარშრუტებზე tuning გარეშე.
ლოგოები ნედლეული მოთხოვნის სხეულით და PII.
არ არსებობს ნორმალიზაცია/ზომისა და შემოვლითი შეზღუდვები, DoS პარსინგისთვის.
გამოტოვება 'შინაარსის ტიპი '/შემოწმება - პოლიგლოტის შეტევები.
egress ფილტრების არარსებობა SSRF ღრუბლის მეტამონაცემისთვის.
ერთი ზოგადი პროფილი გარე და შიდა API- სთვის.
უკონტროლო გამონაკლისები „პარტნიორისთვის“ არის პერიმეტრის ხვრელები.

12) iGaming/ფინანსების სპეციფიკა

გაძლიერებული პროფილები გადახდის/გამონაბოლქვი სახელურებზე: მცირე ზომის ბოდი ლიმიტები, მკაცრი სქემები, დენის სიები account/IBAN/PAN ველებისთვის (შენიღბვა, ფორმატის შემოწმება).
ვებჰუკი PSP/KYC: HMAC ხელმოწერა/მუტალური TLS, ინდივიდუალური WAF პროფილები, ანტი-რეპლეი.
Geo/ASN ფილტრები და ქცევითი ლიმიტები, რათა თავიდან იქნას აცილებული ბოტის რეგისტრაციები და ბონუს აბიუზი.
ინციდენტების ჟურნალები უცვლელი (აუდიტი), შენახვა იურისდიქციებზე.

13) მზადყოფნის ჩეკის სია

• ორ ფენიანი WAF (CDN + L7), ერთი ნორმალიზაცია და ზომების ლიმიტები.
• OWASP CRS შედის per-route- ის კასტომიური წესები; JSON Schema/Protobuf write სახელურებზე.
• პოლიტიკოსები Content-Type/charset; ორმაგი დეკოდირების აკრძალვა/NULL/traversal.
• SSRF-egress ბლოკი კერძო დიაპაზონებზე/metadata; DNS-rebinding დაცვა.
• Rate/Quta/Concurrence და inti-bot (Challengji) საჯარო ფორმებზე.
• Shadow/Report-Only → canary → enforce; ავტო-როლბაკი SLO და FP.
• მეტრიკები/ლოგები/ნიღბები; დაშბორდები „ტოპ წესები “/FP.
• ვირტუალური პატჩისა და RCA ფლეიბუკები; რეგულარული შემოვლითი ტესტები.
• ცალკეული პროფილები PSP/KYC ვებჰუკებისთვის, გადახდის სახელურებისა და შიდა API- სთვის.

14) TL; DR

ააშენეთ თავდაცვა ფენების მიხედვით: სქემების/ტიპების ნორმალიზაცია და შეზღუდვები - პარამეტრიზაცია - WAF (CRS + კასტა) - rate/bot ფილტრები და egress SSRF ბლოკი. Tune per-route, დაიწყეთ ახალი წესები shadow-canary- ში, დააკვირდით მეტრიკებს/FP და გააკეთეთ „ვირტუალური პატჩი“ კოდის ფიქსაციამდე. გადახდის/ვებჰუკის გზებისთვის - ცალკეული მკაცრი პროფილები, HMAC/mTLS და მინიმალური ნდობის ფანჯრები.