Rovnováha medzi nahrávaním a blokovaním vo WAF

Informatec Digital » Zdroje » Rovnováha medzi nahrávaním a blokovaním vo WAF

Nájdenie správnej rovnováhy medzi protokolovaním a blokovaním v rámci WAF sa stalo jedným z najčastejších problémov bezpečnostných a prevádzkových tímov. Firewall webových aplikácií dokáže zastaviť veľmi závažné útoky, ale ak je nakonfigurovaný príliš agresívne, môže blokovať legitímne nákupy, prístup alebo volania API. Ak je nakonfigurovaný príliš voľne, nakoniec slúži takmer výlučne ako dekorácia. Kľúčom je starostlivo nastaviť, kedy protokolovať, kedy počítať, kedy povoliť a kedy blokovať.

V tomto článku sa ponoríme do toho, ako dosiahnuť túto rovnováhu pomocou moderných funkcií WAF (zoznamy povolených položiek, pravidlá založené na frekvencii, režimy učenia, integrácia SIEM, strojové učenie atď.), podporených konkrétnymi príkladmi z AWS WAF, ModSecurity, cloudových WAF a lokálnych riešení . Uvidíte, ako obmedziť falošné poplachy bez zníženia úrovne ochrany, ako organizovať politiky podľa aplikácie a ako používať protokolovanie ako spojenca, nie ako neustály, nezvládnuteľný zdroj šumu.

Čo je WAF a prečo je registrácia taká dôležitá?

Firewall webových aplikácií funguje ako inteligentná vrstva medzi používateľom a serverom a analyzuje prevádzku HTTP/HTTPS v reálnom čase. Na rozdiel od tradičného sieťového firewallu, ktorý monitoruje porty a IP adresy, WAF sa ponára hlbšie: URL adresy, parametre, telá požiadaviek, hlavičky, súbory cookie, metódy HTTP a ďalšie.

Jeho úlohou je detekovať a zastaviť typické útoky na 7. vrstve : SQL injection, XSS, LFI/RFI, útoky na riadenie prístupu, zneužívanie API, agresívne scraping, hrubú silu a dokonca aj určité vzorce DDoS na úrovni aplikácií. Na to sa spolieha na súbory pravidiel, podpisov a bezpečnostných politík, ktoré sa neustále aktualizujú.

Záznamy sú druhou stranou mince. Každé rozhodnutie WAF – povoliť, zablokovať alebo iba započítať – môže byť sprevádzané podrobnou udalosťou v záznamoch . Tieto záznamy umožňujú:

• Vyšetrovanie incidentovzrekonštruovať, čo sa stalo a ako došlo k pokusu o zneužitie zraniteľnosti.
• Upraviť pravidlá: detekcia falošne pozitívnych výsledkov zistením, ktoré legitímne požiadavky WAF blokuje.
• Dodržiavajte predpisypreukázať existenciu aktívnych kontrol (PCI DSS, GDPR, interné audity atď.).
• Napĺňanie SIEMkorelovať útoky na aplikácie s udalosťami v sieti, systéme, identite atď.

Problém je v tom, že zle naladený WAF môže zaplniť protokoly tisíckami irelevantných udalostí , čo znemožňuje nájsť to dôležité a navyše spôsobuje neodôvodnené odmietnutie legitímnej prevádzky. Tu prichádza na rad umenie hrania sa s režimami protokolovania, počítania a blokovania.

Bezpečnostné modely vo WAF: zoznamy blokovaných, zoznamy povolených a hybridný prístup

Väčšina moderných WAF kombinuje niekoľko prístupov k filtrovaniu, čo priamo ovplyvňuje spôsob zaznamenávania a blokovania požiadaviek . Vo všeobecnosti môžeme identifikovať dve klasické filozofie a veľmi bežný hybridný model.

WAF založený na blokovacích zoznamoch sa riadi negatívnym bezpečnostným modelom. Jeho základným princípom je: „Povoľujem všetko okrem toho, o čom viem, že je škodlivé.“ Funguje na princípe známych útokov (SQL injection, XSS, vzory botov atď.) a pravidiel, ktoré definujú, čo sa považuje za podozrivé. Spočiatku je jednoduchšie ho nasadiť, ale spoliehanie sa výlučne na tento model riskuje, že nové vektory alebo varianty útoku preniknú bez povšimnutia.

WAF s povoleným zoznamom funguje opačným spôsobom: „blokuje všetko okrem toho, čo je výslovne povolené“. Je založený na modeli pozitívnej bezpečnosti. Akceptovaná je iba prevádzka, ktorá zodpovedá definovanému legitímnemu správaniu – trasy, metódy, parametre, formáty, veľkosti atď. Je to oveľa bezpečnejšie, ale vyžaduje si to značné doladenie a ak nie je správne pripravené, môže spočiatku generovať falošne pozitívne výsledky.

Vzhľadom na výhody a nevýhody každého prístupu sa čoraz bežnejším stáva hybridný model kombinujúci zoznamy povolených a blokovaných položiek . V tomto scenári sa definujú očakávané profily návštevnosti (napríklad čo predstavuje bežné prihlásenie alebo žiadosť o platbu) a súčasne sa používajú podpisy a heuristika na detekciu typických škodlivých vzorcov. Na účely protokolovania tento hybridný prístup umožňuje:

• Označiť ako vysokoriziková udalosť čo porušuje zoznam povolených položiek.
• Považovať za upozornenia so strednou/nízkou prioritou všeobecné vzory blokovaných zoznamov.
• Pred aktiváciou bloku použite režim „počítania“, aby ste zistili, čo by porušilo pravidlo.

WAF v sieti, na hostiteľovi a v cloude: vplyv na protokolovanie a uzamykanie

Model nasadenia WAF výrazne ovplyvňuje spôsob spracovania protokolovania a blokovania prevádzky. Protokolovanie požiadaviek na sieťovom zariadení nie je to isté ako ich protokolovanie na agentovi v rámci servera alebo v spravovanej cloudovej službe.

Sieťový WAF sa zvyčajne nasadzuje ako fyzické alebo virtuálne zariadenie v rámci infraštruktúry, medzi internetom a aplikáciami. Ide o klasický prístup, ktorý používajú výrobcovia ako F5. Ponúka výhodu vysokého výkonu a podrobnej kontroly , ale konfigurácia a správa môžu byť zložité. Záznamy sa zvyčajne odosielajú do syslogu alebo centrálneho SIEM a je dôležité starostlivo filtrovať uložené údaje, aby sa predišlo preťaženiu úložiska a analytických nástrojov a aby sa diagnostikovali problémy v IP a DNS sieťach.

Hostiteľské WAFy bežia na rovnakých serveroch (alebo kontajneroch), kde sa nachádza aplikácia, zvyčajne ako modul alebo agent (napríklad ModSecurity integrovaný do Nginx alebo Apache; jeho kombinácia s posilňovaním Linuxu pomocou SELinuxu zlepšuje bezpečnostnú pozíciu). Tento model umožňuje širší kontext aplikácie a vysoko špecifické pravidlá pre každú službu, ale za cenu spotreby lokálnych zdrojov a požiadavky na distribuovanejšiu správu protokolov. Protokoly je možné ukladať do lokálnych súborov a potom preposielať alebo integrovať s centralizovanými službami protokolovania.

Cloudové WAF (Cloudflare, Akamai, Imperva Cloud, AWS WAF atď.) sa integrujú s vyrovnávačmi záťaže, CDN alebo virtuálnymi sieťami. Poskytovatelia zvyčajne ponúkajú dashboardy a export protokolov do S3, BigQuery, vzdialených syslogov alebo SIEM. Vo všeobecnosti sa jednoduchšie nastavujú, ale musíte prispôsobiť svoje zásady protokolovania modelu poskytovateľa: typy udalostí, doby uchovávania, filtre závažnosti atď.

Výber jedného alebo druhého modelu nie je len technickým rozhodnutím, ale aj otázkou toho, ako chcete vyvážiť protokolovanie a uzamykanie: cloudovo spravovaná služba zjednodušuje mnoho aspektov, ale možno budete chcieť mať absolútnu kontrolu nad tým, kde sa protokoly ukladajú kvôli pravidlám dodržiavania predpisov alebo zásadám dôvernosti, čo vás tlačí k lokálnym alebo hybridným modelom.

Podmienky, pravidlá a webové ACL: ako WAF rozhoduje o blokovaní, povolení alebo iba registrácii

Bez ohľadu na výrobcu sú všetky moderné WAF založené na koncepte podmienok prístupu, pravidiel a politík . Pochopenie tejto koncepcie je kľúčom k úspešnému používaniu režimov počítania, protokolovania a uzamykania v produkčnom prostredí.

Podmienky opisujú , ktorá časť požiadavky sa kontroluje: zdrojová IP adresa, konkrétne hlavičky HTTP (Host, User-Agent, Accept, Content-Type…), parametre dopytu, telo požiadavky, súbory cookie, metóda HTTP, krajina pôvodu atď. Napríklad v AWS WAF Classic môžete definovať podmienku IP adresy s až 10 000 adresami alebo rozsahmi alebo podmienku zhody reťazca na časti URL adresy.

Pravidlá kombinujú jednu alebo viacero podmienok a priraďujú im zámer: povoliť, blokovať alebo počítať. Ak má pravidlo viacero podmienok, zvyčajne sa vyhodnocujú logickým operátorom AND : všetky podmienky musia byť splnené, aby sa pravidlo spustilo. Bežné pravidlo bez podmienok v praxi nezodpovedá ničomu a jeho akcia sa nikdy nespustí.

Mnohé siete WAF vrátane AWS WAF majú tiež pravidlá založené na sadzbách . Tieto pravidlá počítajú požiadavky prichádzajúce z IP adresy (alebo skupiny IP adries, ktoré spĺňajú určité podmienky) počas časového okna, napríklad piatich minút. Ak sa prekročí prahová hodnota – napríklad 1 000 požiadaviek za päť minút – pravidlo sa uplatní: blokovanie alebo jednoduché počítanie. Toto je veľmi užitočné pre:

• ovládanie hrubá sila na prihlasovacích formulároch.
• Obmedzte agresívne scrapingovanie alebo hrubé boty.
• Zmierňovanie určitých typov DDoS útokov na úrovni aplikácie.

Ďalšou úrovňou je webový ACL (zoznam riadenia prístupu) . Tu sú pravidlá zoskupené a je definované poradie vyhodnocovania a predvolená akcia (POVOLIŤ alebo ZABLOKOVAŤ). Požiadavka prechádza pravidlami v poradí; ak sa zhoduje s jedným, použije sa jej akcia a vyhodnocovanie ostatných sa zastaví. Ak sa nezhoduje so žiadnym pravidlom, použije sa predvolená akcia definovaná v ACL.

Pokiaľ ide o vyváženie protokolovania a blokovania, v ACL sa rozhodujete, či chcete, aby bol systém štandardne tolerantný (POVOLENÉ a blokovanie iba podľa špecifických pravidiel) alebo vysoko reštriktívny (BLOKOVANÉ okrem výnimočných prípadov). Okrem toho mnohé riešenia umožňujú nastaviť pravidlá v režime „počítania“ v rámci ACL, takže protokolujú zhody, ale neblokujú prevádzku – ideálne pre fázu ladenia.

Biele zoznamy a redukcia šumu v protokoloch

Zoznamy povolených položiek sú základným nástrojom na zníženie falošne pozitívnych výsledkov a šumu v protokole . Myšlienka je jednoduchá: v určitých kontextoch poviete funkcii WAF, aby neaplikovala smernicu alebo súbor pravidiel na konkrétnu prevádzku, ktorú ste už kategorizovali ako dôveryhodnú alebo o ktorej viete, že je mimo normy, ale legitímna.

Napríklad v AWS WAF môžete vytvoriť pravidlá zoznamu povolených položiek, takže ak požiadavka prichádza z konkrétnej IP adresy alebo rozsahu , alebo ak sa zhoduje so známym vzorom URL a metódou HTTP, určité kontroly podpisov sa nepoužijú. To pomáha:

• Zabráňte interným API, ktoré používajú „zvláštne“ vzory generujú neustále falošne pozitívne výsledky.
• Znížte latenciu spôsobenú hĺbkovou kontrolou v prevádzke, ktorú už považujete za dôveryhodnú.
• Znížte objem nepotrebných záznamov v protokoloch WAF.

Na platformách ako ModSecurity sa odporúča neupravovať štandardné pravidlá (napr. OWASP Core Rule Set), ale skôr vytvárať špecifické výnimky podľa ID pravidla pre určité parametre, cesty alebo používateľov. To vám umožňuje zachovať celkovú ochranu bez vytvorenia obrovských zraniteľností deaktiváciou celých pravidiel na celom webe.

Kľúčom je chirurgicky upravovať zoznamy povolených položiek , nie uviesť všeobecný prístup. Je oveľa lepšie vylúčiť konkrétnu kombináciu (pravidlo X + parameter Y v URL Z), ako globálne zakázať pravidlo X. Týmto spôsobom zostane protokolovanie užitočné a nevytvoríte zbytočné slepé miesta.

Pravidlá a obmedzenia protokolu: kedy blokovať, kedy varovať

Mnohé WAF obsahujú sadu pravidiel sanitácie HTTP protokolu, ktoré fungujú ako prvý filter pre chybnú alebo podozrivú prevádzku . Tieto pravidlá kontrolujú požadované hlavičky, metódy, veľkosti argumentov atď. a sú častým zdrojom dobrej ochrany aj falošne pozitívnych výsledkov, ak nie sú správne pochopené.

Niektoré veľmi bežné príklady:

• Chýbajúca hlavička prijatia (Chýbajúca hlavička Accept): Toto nie je striktne porušenie RFC, ale mnoho požiadaviek bez tejto hlavičky pochádza z automatizovaných nástrojov alebo zle napísaných skriptov. Môže to ovplyvniť vlastné rozhrania API alebo klientov, ktorí ju neodosielajú. V mnohých prostrediach sa uprednostňuje protokolovanie a počítanie pred priamym blokovaním.
• Chýbajúca hlavička hostiteľaPodľa štandardov HTTP/1.1 je hlavička Host povinná. Potrebujú ju aj WAF na určenie, ktorú politiku použiť. Blokovanie v tomto prípade je zvyčajne rozumné, ale môže generovať falošne pozitívne výsledky počas testovania alebo v dôsledku nesprávne nakonfigurovanej internej prevádzky; pred povolením prísneho blokovania je vhodné monitorovať protokoly.
• Chýbajúca hlavička používateľského agentaToto pravidlo sa snaží obmedziť rudimentárne boty a neidentifikovanú prevádzku. Problém je v tom, že mnohé legitímne API nemusia odosielať používateľského agenta. Najrozumnejším prístupom je zvyčajne zaznamenať ho a ak sa zistí konzistentné a legitímne API, pridať svoju IP adresu alebo vzor do zoznamu povolených.
• Validácia GET/HEAD s telom príkazuHoci RFC striktne nezakazuje odosielanie tela s požiadavkami GET alebo HEAD, nie je to bežná prax a môže to naznačovať pokusy o obchádzanie. V mnohých prípadoch je prvým krokom zaznamenať všetky tieto požiadavky a ak sa zistí, že ide o podozrivé anomálie, pokračovať v ich blokovaní.
• Chýbajúci typ obsahu s telomAk je prítomné telo, ale nie Content-Type, je to jasný znak nesprávneho použitia protokolu alebo pokusu o vyhnutie sa analýze. V týchto prípadoch má zvyčajne zmysel agresívnejší prístup k blokovaniu, najmä v prostrediach s pripojením na internet.

Okrem týchto pravidiel protokolu sa často nachádzajú aj limity argumentov na ochranu pred záplavami na úrovni aplikácií a útokmi DoS. Napríklad:

• Maximálny počet argumentov na požiadavku (v niektorých WAF predvolene 255).
• Maximálna dĺžka jedného argumentu (napríklad 400 znakov).
• Celková kombinovaná veľkosť všetkých argumentov (napríklad 64 000 bajtov).

Tieto hodnoty sú pre mnohé aplikácie primerané, ale existujú prípady – zložité nahrávanie formulárov, pokročilé filtre, veľké načítania JSON – kde sa vyskytujú falošne pozitívne výsledky. V týchto scenároch je najrozumnejším prístupom začať protokolovaním a počítaním , skontrolovať, ktoré koncové body porušujú limity, a upraviť iba pre tieto trasy, a nie zrušiť všetky limity pre celú stránku.

Falošne pozitívne výsledky: ako ich odhaliť a nezomrieť pri snahe

Falošne pozitívny výsledok je legitímna požiadavka, ktorú WAF identifikuje ako škodlivú a zablokuje alebo označí ako útok. Sú nevyhnutné, najmä ak máte povolené komplexné sady pravidiel, ako je OWASP CRS, ale dajú sa profesionálne spravovať, aby sa nestali každodennou bolesťou hlavy.

Detekcia falošne pozitívnych výsledkov začína dôkladnou kontrolou protokolov . To zahŕňa preskúmanie toho, ktoré požiadavky sú blokované, ktoré pravidlo ich spúšťa a kontext, v ktorom sa vyskytujú (URL, parametre, používateľ, pôvod atď.). Vizuálne nástroje a dashboardy môžu pomôcť identifikovať nárasty chýb 403 alebo nezvyčajné vzorce.

Poskytovatelia cloudových služieb aj komunita ModSecurity dôrazne odporúčajú použiť režim simulácie alebo počítania . V tomto režime pravidlá, ktoré chcete testovať, zaznamenávajú každú zhodu, ale neblokujú ich. To vám napríklad umožňuje vidieť, koľko legitímnych požiadaviek by nové pravidlo SQLi zablokovalo predtým, ako by ste sa odvážili ho aktivovať v produkčnom prostredí.

Je tiež dobrý nápad otestovať pravidlá v testovacom alebo predprodukčnom prostredí , ktoré prijíma skutočnú alebo simulovanú prevádzku. Nástroje ako OWASP ZAP alebo skripty na prehrávanie prevádzky vám môžu pomôcť simulovať legitímne vzorce a známe útoky na otestovanie správania WAF.

Okrem toho je dôležité zvážiť prevádzkový a reputačný dopad falošne pozitívnych výsledkov: prerušenia platieb, zlyhania registrácie používateľov, kritické volania API, ktoré zlyhajú bez vysvetlenia – to všetko môže mať priame náklady na príjmy a imidž značky. Nadmerný počet falošne pozitívnych výsledkov tiež zahlcuje bezpečnostný tím upozorneniami, ktoré neprinášajú pridanú hodnotu, čo sťažuje identifikáciu skutočných incidentov.

Stratégie na úpravu pravidiel a inteligentné používanie registra

Riešenie falošne pozitívnych výsledkov nespočíva v vypínaní pravidiel, kým „všetko nefunguje“, ale v chirurgicky presnom doladení funkcie WAF . Tu prichádzajú na rad osvedčené postupy, ako napríklad tieto:

Po prvé, vyhnite sa globálnemu zakazovaniu pravidiel. Je lepšie vytvoriť veľmi špecifické výnimky : vylúčiť ID pravidla iba pre konkrétnu trasu, pre určité parametre alebo pre internú prevádzku. Týmto spôsobom zostanete chránení vo zvyšku aplikácie a budete uchovávať užitočné protokoly.

Po druhé, pred blokovaním využite režim počítania . Aktivácia nových pravidiel spočiatku iba v režime protokolovania vám umožňuje merať, koľko legitímnych požiadaviek by to ovplyvnilo. Toto môžete doplniť upozorneniami v SIEM, aby ste rýchlo zistili, či pravidlo generuje abnormálny objem zhôd.

Po tretie, integrujte WAF so systémom SIEM alebo centralizovanou platformou na zaznamenávanie . To uľahčuje koreláciu udalostí WAF s inými indikátormi: nezvyčajná aktivita systému, zlyhania hromadného overovania, podozrivé zmeny konfigurácie atď. Pomáha to tiež uprednostniť pravidlá, ktoré treba upraviť ako prvé, na základe závažnosti a frekvencie udalostí.

Po štvrté, zdokumentujte každú zmenu: ktoré pravidlo bolo doladené, pre ktorý koncový bod, z akého odôvodnenia a s akými dôkazmi. V tomto smere môže byť užitočné konzultovať manuály k serveru . Táto dokumentácia nielen pomáha udržiavať internú kontrolu, ale je tiež neoceniteľná pri bezpečnostných auditoch a kontrolách, kde chcete preukázať, že kontroly nie sú ľahkovážne deaktivované.

Automatizácia, strojové učenie a adaptívne pravidlá v WAF

S rastom aplikácií a komplexnejším prevádzkou sa manuálna správa WAF stáva nereálnou. Tu prichádza na rad automatizácia, pokročilá analýza protokolov a v niektorých prípadoch aj strojové učenie.

Po prvé, integrácia so SIEM vám umožňuje vytvárať korelačné pravidlá a automatizované reakcie : napríklad, ak sada IP adries opakovane spúšťa pravidlá injekcií alebo XSS, môžete vygenerovať automatickú akciu na pridanie týchto IP adries do dočasného zoznamu blokovaných adries alebo na posilnenie úrovne kontroly.

Po druhé, niektoré WAF obsahujú režimy strojového učenia , ktoré sledujú legitímnu prevádzku počas definovaného obdobia. Na základe týchto údajov navrhujú alebo upravujú prahové hodnoty, vzory a profily normálneho správania. To pomáha znižovať počet falošne pozitívnych výsledkov, keď sa pravidlá prepnú do režimu blokovania, a zisťovať následné odchýlky prevádzky.

Vo výskumnom a laboratórnom prostredí sa techniky riadeného učenia používajú na trénovanie modelov, ktoré rozlišujú medzi legitímnou a škodlivou prevádzkou, a zdokonaľujú pravidlá, ktoré sa potom používajú v produkčnom prostredí. Hoci to nie je zázračné riešenie, tento prístup môže pomôcť odhaliť jemné vzory , ktoré klasické pravidlá založené na podpisoch nedokážu ľahko odhaliť.

Nakoniec, nepretržité automatizované testovanie (pomocou nástrojov ako OWASP ZAP, vlastných skriptov alebo CI/CD kanálov) vám umožňuje overiť, či zmeny v WAF nenarušia kritické funkcie ani nezanechajú zjavné zraniteľnosti. Integrácia týchto testov do cyklu nasadzovania robí z zabezpečenia prirodzenú súčasť vývojového procesu, a nie len opravu na poslednú chvíľu.

Návrh politiky pre každú aplikáciu a čierne listiny pre každú službu

V zložitých prostrediach – napríklad u poskytovateľa hostingu alebo poskytovateľa internetových služieb – nestačí jedna politika WAF, najmä ak ide o tieňové IT . Je bežné, že za tým istým vyrovnávačom záťaže je viacero domén alebo aplikácií, pričom každá má iné bezpečnostné potreby a profily prevádzky . V tomto prípade sa navrhovanie politík a zoznamov špecifických pre danú službu stáva nevyhnutným.

Ilustratívnym príkladom je vyrovnávač záťaže HTTP/S, ktorý funguje ako reverzný proxy pre viacero lokalít (napr. www.company1.com a www.company2.com) za jednou virtuálnou IP adresou. V tomto scenári je možné WAF nakonfigurovať tak, aby vyhodnotil hlavičku hostiteľa a zdrojovú IP adresu hneď po prijatí požiadavky, ešte predtým, ako sa dostane k modulu vyrovnávania záťaže.

Logika by bola približne takáto: WAF kontroluje, či kombinácia SERVER_NAME (Host) a IP adresy klienta zodpovedá čiernej listine špecifickej pre danú lokalitu. Ak je IP adresa uvedená ako blokovaná pre www.company2.com, ale nie pre www.company1.com, odpoveď 403 Forbidden sa odošle iba v prvom prípade. „Čistá“ prevádzka sa potom odošle do modulu vyvažovania záťaže, ktorý rozhodne, ktorý backend obslúži požiadavku.

To umožňuje napríklad udržiavať čierne listiny špecifické pre doménu namiesto jedného globálneho zoznamu pre celý prístupový bod. Na úrovni protokolovania sa každé odmietnutie zaznamenáva do syslogu s podrobnosťami, ako je ID pravidla, zhodná podmienka, URL adresa, hostiteľ a IP adresa klienta, čo uľahčuje následnú analýzu a rozšírenie alebo ladenie týchto zoznamov.

Ponaučenie z príbehu je, že čím viac sú vaše politiky segmentované (podľa aplikácie, prostredia, typu používateľa), tým lepšie dokážete nájsť rovnováhu medzi protokolovaním a blokovaním: na administratívnych portáloch môžete byť veľmi prísni a na informačných webových stránkach o niečo flexibilnejší, napríklad s dôkazmi v protokoloch, prečo bolo každé rozhodnutie prijaté.

Viac než len klasický WAF: ochrana WAAP a API

Situácia s hrozbami sa nezastavila. Dnes je mnoho aplikácií cloudových, využíva architektúry mikroslužieb a sprístupňuje verejné aj súkromné ​​API , čo z nich robí hlavné ciele útočníkov. Tradičné WAF sa vyvinuli do širších platforiem známych ako WAAP (Web Application and API Protection) alebo WAAS (Web Application & API Security).

Tieto riešenia nielen automaticky vyhľadávajú webové aplikácie, ale tiež identifikujú koncové body API , akceptujú špecifikácie ako OpenAPI alebo Swagger a používajú túto definíciu na kontrolu súladu požiadaviek: očakávané typy údajov, povolené parametre, limity veľkosti atď. V závislosti od koncového bodu (napríklad takého, ktorý spracováva vysoko citlivé údaje) je možné použiť oveľa vyššiu úroveň kontroly a blokovania.

Na úrovni protokolovania má WAAP tendenciu generovať kontextovo bohaté udalosti : ktorý presný koncový bod API bol napadnutý, ktorá operácia (GET, POST, PUT…), ktorý používateľ alebo token bol zapojený, ktorá časť špecifikácie bola porušená atď. To umožňuje presnejšie rozhodnutia o blokovaní, namiesto spoliehania sa výlučne na generické vzory užitočného zaťaženia.

Okrem toho mnohé nástroje WAAP zahŕňajú ochranu pred DoS špecifickými aplikáciami a API, filtrovanie geolokácie, správu reputácie IP adries, detekciu botov a scrapingu a možnosti prispôsobenia úrovní upozornení pre jednotlivé služby. Opäť ide o flexibilitu pri rozhodovaní, kde chcete robustnejší prístup a kde chcete uprednostniť plynulú prevádzku bez toho, aby ste obetovali spoľahlivú databázu protokolov na vyšetrovanie akýchkoľvek incidentov.

Dobre vyladený WAF – či už klasický, založený na WAAP alebo integrovaný do cloudového ekosystému – sa stáva základnou súčasťou modernej obrany aplikácií a API, schopnou kombinovať podrobné protokolovanie, inteligentné blokovanie a neustále prispôsobovanie sa meniacej sa scenérii hrozieb.