OWASP ZAP: co to jest i 10 typowych sprawdzeń

Czym jest ZAP

ZAP (Zed Attack Proxy), w wielu miejscach nadal nazywany OWASP ZAP, to darmowy skaner bezpieczeństwa aplikacji internetowych o otwartym kodzie. Jego strona opisuje go jako niezależny projekt open source. Działa jak pośrednik między przeglądarką a aplikacją: widzi każde zapytanie i odpowiedź, więc potrafi je analizować.

Używa go zarówno człowiek, który ręcznie bada aplikację, jak i automat w systemie testów, który uruchamia go przy każdej zmianie kodu.

Skan Baseline: pasywny, bez ataków

W automatycznych testach najczęściej uruchamia się tryb Baseline. Według dokumentacji ZAP przechodzi wtedy po aplikacji pająkiem (domyślnie przez minutę), a potem czeka na zakończenie analizy pasywnej i zgłasza wyniki. Dokumentacja zaznacza, że skrypt nie wykonuje żadnych prawdziwych ataków i trwa najwyżej kilka minut.

To ważne rozróżnienie. Skan pasywny czyta to, co aplikacja i tak odpowiada każdemu odwiedzającemu: nagłówki, ciasteczka, kod strony. Skan aktywny dopiero wysyła spreparowane zapytania, żeby sprawdzić, czy aplikacja da się oszukać, dlatego wolno go kierować tylko na własne systemy albo za zgodą ich właściciela.

10 typowych sprawdzeń

Nazwy poniżej pochodzą z listy alertów ZAP. Które z nich się pojawią, zależy od wersji i konfiguracji, a samo zgłoszenie to sygnał do sprawdzenia, nie dowód włamania.

1. Content Security Policy (CSP) Header Not Set. Brak nagłówka, który mówi przeglądarce, skąd wolno ładować skrypty. Ogranicza skutki wstrzyknięcia obcego kodu.
2. Missing Anti-clickjacking Header. Stronę można osadzić w cudzej ramce i nakłonić użytkownika do kliknięcia czegoś, czego nie widzi.
3. X-Content-Type-Options Header Missing. Przeglądarka może zgadywać typ pliku zamiast ufać serwerowi.
4. Strict-Transport-Security Header Not Set. Przeglądarka nie dostaje polecenia, by z tą stroną łączyć się zawsze po HTTPS.
5. Cookie No HttpOnly Flag. Skrypt na stronie może odczytać ciasteczko, na przykład sesji.
6. Cookie without SameSite Attribute. Ciasteczko jest wysyłane także w zapytaniach z obcych stron, co ułatwia ataki typu CSRF.
7. Server Leaks Version Information via “Server” HTTP Response Header Field. Serwer zdradza, jakiego oprogramowania w jakiej wersji używa.
8. Information Disclosure - Suspicious Comments. W kodzie strony zostały komentarze, które mogą naprowadzać atakującego.
9. Cross-Domain JavaScript Source File Inclusion. Strona ładuje skrypty z innych domen, więc jej bezpieczeństwo zależy też od nich.
10. Vulnerable JS Library. Strona używa biblioteki JavaScript w wersji ze znaną luką.

Często obok nich pojawiają się jeszcze „Re-examine Cache-control Directives”, „Permissions Policy Header Not Set” i „Sub Resource Integrity Attribute Missing”.

Czego skan pasywny nie powie

Czysty wynik skanu Baseline nie znaczy „aplikacja jest bezpieczna”. Skan nie loguje się jako użytkownik, nie sprawdza, czy rodzic z jednej klasy może zajrzeć do drugiej, i nie próbuje wstrzykiwać złośliwych danych. Do tego potrzebne są testy uprawnień napisane pod konkretną aplikację, skan aktywny i test penetracyjny. Skan Baseline to tani, powtarzalny pierwszy filtr, nic więcej.

Jak jest u nas

W ClassKasie, CzynszOK i Kasandro skan Baseline uruchamia się w każdym pull requeście na zbudowanej aplikacji i przerywa build przy nowych ustaleniach. Skan się nie loguje, więc ekranów po zalogowaniu nie obejmuje. Pełny obraz tego, co sprawdzamy w grupie veinito., jest na stronie o bezpieczeństwie.