Co tester powinien wiedzieć o bezpieczeństwie? - teoretyczne wprowadzenie do testów bezpieczeństwa aplikacji webowych — Kodołamacz — Kursy AI, bootcampy, studia podyplomowe i szkolenia IT

Według udostępnionego przez Acunetix raportu dotyczącego bezpieczeństwa aplikacji webowych prawie 50% stron internetowych dostępnych w Internecie zawiera poważne podatności. Ich obecność stanowi zagrożenie dla użytkowników aplikacji oraz ryzyko strat finansowych, a zdarza się, że błędy te nie są trudne do wykrycia i wykorzystania.

W dzisiejszym wpisie przybliżymy tematykę testów bezpieczeństwa (pentestów), związaną z tym obszarem terminologię i omówimy rodzaje podatności występujących w aplikacjach webowych.

W obszarze testów bezpieczeństwa wykorzystywane jest charakterystyczne słownictwo, dlatego zaczniemy od paru definicji, które pozwolą lepiej zrozumieć dalszą część artykułu.

Wektor ataku – czynnik, który pozwala na zaatakowanie aplikacji – np. jeżeli atakujemy blog w sieci, to wektorem ataku może być wtyczka do Wordpressa, która zawiera niezałataną podatność.

Podatność – słaby punkt w aplikacji, który może zostać wykorzystany w ataku – np. formularz, którego zawartość jest przekazywana do serwera bez walidacji.

Exploitacja – wykorzystanie podatności w celu wyrządzenia szkód użytkownikom aplikacji lub zaburzenia jej dostępności.

Testy bezpieczeństwa przeprowadzane są przez specjalistów – pentesterów. Zwykle pentesterami zostają osoby z doświadczeniem programistycznym, administracyjnym lub sieciowym, jednak niektóre podatności to „low hanging fruit” i z perspektywy QA również warto umieć je wyszukiwać. Oczywiście nie zachęcam do delegowania całego procesu weryfikacji aplikacji pod kątem bezpieczeństwa w ręce testerów, natomiast uważam, że wykrywanie podstawowych podatności i błędów w konfiguracji aplikacji może być im powierzone, co pozwoli na szybkie wdrażanie poprawek w tworzonym oprogramowaniu. Każda z luk, na jakie można natknąć się w aplikacjach może zostać sklasyfikowana, jako zaburzenie jednej z trzech cech charakteryzujących bezpieczeństwo.

poufność (Confidentiality) (Czy odpowiednie osoby mają dostęp do odpowiednich danych?)
integralność (Integrity) (Czy dane są spójne i godne zaufania?)
dostępność (Availability) (Czy aplikacja zapewnia satysfakcjonujący poziom dostępności? Czy nie jest awaryjna? Czy nie można w prosty sposób jej przeciążyć?)

Jest to tak zwana „triada CIA”.

Poufność informuje nas, czy dane są dostępne jedynie dla użytkowników, którzy mają do nich uprawnienia. Integralność – czy dane nie mogą być edytowane przez użytkownika bez odpowiednich uprawnień, zaś dostępność – o stopniu awaryjności aplikacji i tym, jak często jest ona niedostępna dla użytkowników.

Jak w większości dziedzin, również w testach bezpieczeństwa podejmowane są próby standaryzacji. W obszarze aplikacji webowych najbardziej znaną organizacją jest OWASP (Open Web Application Security Project). OWASP dostarcza darmowe i open-source’owe narzędzia pomocne przy weryfikacji bezpieczeństwa, artykuły, metodologie testów bezpieczeństwa i aplikacje treningowe. Do niedawna OWASP skupiał się jedynie na aplikacjach webowych, natomiast w ostatnim czasie zostały stworzone publikacje dotyczące bezpieczeństwa aplikacji mobilnych oraz IoT. Projektując, rozwijając i testując rozwiązania dotyczące bezpieczeństwa aplikacji webowych zawsze warto odnieść się do dostarczanych przez OWASP materiałów. Poniżej zostało opisane kilka z najciekawszych pozycji.

OWASP Testing Guide

Ponad dwustustronicowa książka poświęcona testom bezpieczeństwa. Zawiera framework, który pozwala na planowanie faz testów bezpieczeństwa a także szeroko opisuje występujące w aplikacjach webowych podatności i podejście do ich testowania. Z perspektywy QA zainteresowanego testami bezpieczeństwa jest to pozycja obowiązkowa i warto przeczytać ten poradnik od deski do deski.

OWASP Top10s

Top10 od OWASP to lista najpoważniejszych występujących w aplikacjach błędów. Aktualnie istnieją następujące zestawienia TOP10:

Rozpoczynając testy bezpieczeństwa danego typu aplikacji zawsze warto odnieść się do powyższych źródeł, żeby wiedzieć na jakich rodzajach błędów skupiać się w pierwszej kolejności.

Przykładowo OWASP Top10 dla aplikacji webowych zawiera następujące klasy podatności i błędów:

A1 – Injection – wstrzyknięcia
A2 – Broken Authentication – błędy uwierzytelnienia
A3 – Sensitive Data Exposure – ujawnienie danych wrażliwych
A4 – XML External Entites – XXE
A5 – Broken Access Control – nieprawidłowa kontrola dostępu (błędy związane z autoryzacją)
A6 – Security Misconfiguration – niepoprawna konfiguracja aplikacji
A7 – Cross-Site Scripting – XSS
A8 – Insecure Deserialization – błędy związane z deserializacją
A9 – Using Components with Known Vulnerabilities – stosowanie komponentów ze znanymi podatnościami (np. podatne moduły npm)
A10 – Insufficient Logging & Monitoring – nieprawidłowe logowanie incydentów bezpieczeństwa Część pozycji z tej listy zostanie poruszona w kolejnych wpisach.

OWASP ASVS

OWASP ASVS (Application Security Verification Standard) to dokument zawierający obszerną checklistę z zaleceniami dotyczącymi testowania i wytwarzania bezpiecznego oprogramowania. W ramach OWASP ASVS wyróżnione są 3 poziomy bezpieczeństwa – poziom pierwszy to poziom jaki powinna spełniać każda aplikacja, poziom drugi dotyczy aplikacji przetwarzających jakiekolwiek dane osobowe i drobne transakcje, zaś poziom trzeci dotyczy aplikacji obsługujących duże transakcje i zawierających poufne dane. https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project

OWASP Cheat Sheets

Na GitHubie OWASPa znajdują się poradniki dotyczące różnych zagadnień związanych zarówno z testowaniem, jak zabezpieczaniem elementów aplikacji webowych.

Podatne aplikacje

W obszarze testów bezpieczeństwa jednym z najlepszych sposobów na naukę jest wykonywanie praktycznych zadań. Sprawdzanie swoich umiejętności na prawdziwych aplikacjach może nieść za sobą konsekwencje prawne, dlatego powstają tak zwane „aplikacje treningowe”. Aplikacje treningowe zawierają przygotowane przez twórców podatności i umożliwiają trening samodzielnego wyszukiwania luk w aplikacjach. Część z nich zawiera także tutoriale, które znacznie przyspieszają naukę. Szczególnie godną polecenia aplikacją jest OWASP WebGoat – składa się z części odpowiadających pozycjom z listy OWASP Top10 dla aplikacji webowych. Dla każdej z klas podatności zawiera teoretyczne wprowadzenie, praktyczne ćwiczenia oraz quizy. Dodatkowo, w aplikacji znajduje się parę zadań typu CTF (Capture the flag - zagadki polegające na wykorzystaniu występujących w aplikacji podatności w celu uzyskania „flagi”). Inne ciekawe (i dość aktulane) aplikacje dostarczane przez OWASP to DVSA (Damn Vulnerable Serverless Application) oraz DVSA (Damn Vulnerable Web Sockets. Więcej podatnych aplikacji można znaleźć np. w tym repozytorium. Trzeba jednak zwrócić uwagę na fakt, że część z aplikacji jest już nieaktualna i wykorzystuje przestarzałe technologie.

Jak wyglądają testy bezpieczeństwa?

Zwykle testy bezpieczeństwa rozpoczynają się od ustalenia zakresu testów – pentester musi wiedzieć, czy testowana jest tylko aplikacja webowa, czy na przykład cała infrastruktura z nią związana? Po ustaleniu zakresu testów, rozpoczyna się faza rozpoznania i gromadzenia informacji. Często testy przeprowadzane są w tzw. ujęciu black-box (tester zna tylko adres IP testowanej aplikacji) lub grey-box (tester zna adresy aplikacji i np. ma dostęp do konta o podstawowym poziomie uprawnień). Istnieje również ujęcie white-box, w którym pentester zna wszystkie szczegóły działania aplikacji i może konsultować się z zespołem tworzącym produkt, jest to jednak podejście znacznie rzadsze. Gromadzone informacje to adresy IP wykorzystywane w aplikacji, wersje oprogramowania, serwerów i frameworków, loginy i adresy mailowe użytkowników aplikacji i wszystko, co może bezpośrednio i pośrednio wpłynąć na przebieg testów. Po zgromadzeniu informacji należy przeanalizować ryzyka związane z aplikacją, wyszukać w oprogramowaniu znane podatności i określić, jakie elementy aplikacji mogą prowadzić do naruszeń bezpieczeństwa. Często są to formularze, których treść jest przesyłana do serwera (komentarze, formularze importu plików). Znalezione i wykorzystane podatności należy umieścić w raporcie z testów, który jest przekazywany zespołowi odpowiedzialnemu za aplikację, a następnie należy zweryfikować poprawki. Dokładniejszy opis przeprowadzania testów zostanie przedstawiony we wpisie poświęconym podatnościom.

Podsumowanie

W dzisiejszym wpisie omówiliśmy podstawowe pojęcia związane z testami bezpieczeństwa i dowiedzieliśmy się czym jest OWASP. W kolejnych wpisach będą poruszane aspekty bardziej techniczne – m.in. tworzenie własnego środowiska do testów bezpieczeństwa oraz podstawowe podatności na jakie możemy się natknąć w aplikacjach webowych.