WAF

WAF (web application firewall) to zapora aplikacyjna dla aplikacji HTTP, która stosuje zestaw reguł do rozmowy HTTP między klientem a serwerem ^[1]. W odróżnieniu od klasycznej zapory sieciowej, która patrzy głównie na adresy i porty, WAF czyta treść żądań: parametry, nagłówki, ciasteczka i ciało. Reguły WAF-a zwykle celują w najczęstsze ataki, takie jak XSS (Cross-Site Scripting) i SQL injection ^[1]. MITRE wymienia zaporę aplikacyjną jako jedną z warstw obrony przed XSS, przydatną, gdy kodu nie da się szybko poprawić, i ocenia jej skuteczność jako umiarkowaną ^[8].

Jak działa

OWASP opisuje WAF jako odwrotność zwykłego proxy: proxy chroni klientów, a WAF chroni serwery i działa jak reverse proxy postawiony przed konkretną aplikacją albo grupą aplikacji ^[1]. Sekurak rozkłada pracę WAF-a na kolejne etapy: przyjęcie żądania, dobór reguł do jego typu, normalizację danych, rozbiór na składniki, zastosowanie reguł, korelację zdarzeń z zapisem w logu i odrzucenie żądania uznanego za złośliwe ^[2].

RYS. 1Droga żądania przez WAF

Do rozpoznawania ataków służą według Sekuraka cztery grupy mechanizmów: sygnatury oparte na wyrażeniach regularnych, wykrywanie anomalii, punktowanie żądań i klientów oraz mechanizmy reputacji ^[2]. Normalizacja jest krytyczna. Jeśli reguły normalizacji i reguły wykrywania są niespójne, w skrajnych przypadkach mogą się wzajemnie wykluczać, a to otwiera drogę do obejścia ^[2].

Rodzaje i modele reguł

OWASP wymienia trzy postaci WAF-a: urządzenie, wtyczkę serwera WWW albo filtr ^[1]. W praktyce spotyka się też usługę chmurową przed stroną. Cloudflare opisuje swój WAF jako mechanizm, który sprawdza przychodzące żądania do stron i API i filtruje niepożądany ruch na podstawie zestawów reguł ^[7]. Obok reguł zarządzanych przez dostawcę są w nim reguły własne i reguły ograniczania liczby żądań, czyli rate limiting ^[7].

Otwartym zestawem reguł jest OWASP CRS, opisany przez twórców jako zestaw ogólnych reguł wykrywania ataków dla ModSecurity i zgodnych z nim zapór, między innymi Coraza ^[3]. CRS ma chronić przed szerokim zakresem ataków, w tym z listy OWASP Top 10, przy minimalnej liczbie fałszywych alarmów ^[3].

Reguły dzielą się na dwa modele bezpieczeństwa ^[4].

W WordPressie

Strony WordPress korzystają z WAF-a na trzech poziomach. Pierwszy to usługa przed serwerem, często połączona z CDN. Drugi to moduł serwera WWW, na przykład ModSecurity z regułami CRS. Trzeci to wtyczka bezpieczeństwa działająca w PHP.

Reguły serwerowe. Projekt CRS utrzymuje osobną wtyczkę reguł z wyjątkami dla WordPressa, aby CRS działał z nim bez zakłóceń ^[5]. Obejmuje ona tylko czysty WordPress bez wtyczek. Fałszywe alarmy wywołane przez wtyczki trzeba usuwać własnymi wyjątkami, a wtyczki motywów i kreatory stron wymagają ręcznego strojenia ^[5]. To typowe źródło fałszywych alarmów: edytor wysyła HTML i skrypty, które dla ogólnej reguły wyglądają jak atak.

Zapora we wtyczce. Wordfence opisuje swoją zaporę jako WAF działający w punkcie końcowym, z głęboką integracją z WordPressem ^[6]. Autorzy podkreślają, że w odróżnieniu od rozwiązań chmurowych nie przerywa ona szyfrowania ^[6]. Reguły w wersji bezpłatnej docierają z 30-dniowym opóźnieniem względem wersji płatnej ^[6]. Zapora działająca w PHP ma dostęp do kontekstu WordPressa, ale zużywa zasoby tego samego serwera. Usługa przed serwerem odciąża go, lecz widzi tylko ruch HTTP.

Wirtualne łatki. Gdy podatność we wtyczce jest znana, a poprawki jeszcze nie ma, WAF może zablokować próby jej wykorzystania. OWASP definiuje wirtualne patchowanie (virtual patching) jako warstwę egzekwowania polityki, która zapobiega wykorzystaniu znanej podatności i je raportuje; wymienia przy tym WAF, IPS i moduły serwera jak ModSecurity ^[4].

Ograniczenia

• WAF nie naprawia kodu. Łatka usuwa przyczynę, reguła tylko utrudnia jej wykorzystanie.
• Obejścia. Sekurak wskazuje, że trudno napisać ogólne reguły dla złożonych ataków bez wiedzy o aplikacji, a błąd w bibliotece użytej przez WAF osłabia cały system ^[2]. Wiele obejść bierze się według autora z niskiej jakości sygnatur ^[2]. Sam CRS w wersji 4 zamknął ponad 500 obejść reguł ^[3].
• Luki w pokryciu. MITRE zauważa, że zapora może nie obejmować wszystkich wektorów wejścia i może omyłkowo odrzucać albo modyfikować poprawne żądania ^[8].
• Utrzymanie. OWASP zaznacza, że dostosowanie WAF-a do aplikacji bywa pracochłonne i trzeba je utrzymywać przy każdej zmianie aplikacji ^[1].
• Błędy logiki, na przykład Broken Access Control, często nie mają sygnatury, bo żądanie wygląda poprawnie.

Dobre praktyki

OWASP zaleca, by nowe reguły wirtualnych łatek najpierw uruchomić w trybie „Log Only” i sprawdzić, że nie blokują zwykłego ruchu, a dopiero potem włączyć blokowanie ^[4]. Ten sam ściągawkowy dokument stawia dwa wymagania: nie blokować legalnego ruchu i nie przepuszczać ataków ^[4]. Pogodzenie ich wymaga przeglądania logów i strojenia wyjątków.

Warto łączyć warstwy. Usługa chmurowa przejmuje DDoS i ruch złośliwych botów, zanim dotrą do serwera. Reguły serwerowe lub zapora we wtyczce łapią ataki na konkretne wtyczki. Kod wtyczek i motywów nadal musi kodować wyjście i sprawdzać uprawnienia, bo WAF jest dodatkową warstwą, a nie zamiennikiem poprawnego kodu ^[8].