Pentester w akcji, czyli jak wygląda testowanie bezpieczeństwa aplikacji webowych.

Na czym polega praca specjalisty, który testuje aplikacje internetowe pod kątem ich odporności na ataki? Jakie błędy najczęściej prowadzą do kompromitacji systemów? Co warto przygotować, zanim zaprosimy pentestera do testu? O tym, jak wygląda profesjonalny test penetracyjny, czego oczekują specjaliści i jakie podatności stają się dziś najbardziej kosztowne dla firm, rozmawiamy z Wiktorią Lewandowską, Security Engineer w ING Hubs. Wywiad przeprowadził Wojciech Samborski, redaktor naczelny serwisu aboutMarketing.pl.

Na czym właściwie polega praca pentestera aplikacji webowych? Czym konkretnie zajmuje się osoba wykonująca takie testy?

Pentesterem czy pentesterką z definicji jest osoba, która mając dany system, przeszukuje go w poszukiwaniu błędów bezpieczeństwa. Symulujemy pracę oszustów próbujących wykraść dokumenty i informacje, czy też zakłócić pracę aplikacji. Podobnie jak designerzy aplikacji zwracamy uwagę na to, aby użytkownik korzystający z aplikacji był pewny tego, że jego dane będą bezpieczne, jego konto nie zostanie przejęte, a on uzyska prawidłowe (niespreparowane) informacje.

Takie sytuacje potrafią narodzić się zarówno ze zwykłego błędu w konfiguracji, jak i ze złożonego scenariusza wykorzystania kilku błędów bezpieczeństwa w odpowiedniej kolejności. Pentester aplikacji webowych zna i umie wykorzystać podatności w nich występujące, potrafi przetestować komponenty aplikacji (w tym API) oraz potrafi napisać dokładny raport z testu penetracyjnego, opowiadający o przebiegu tego testu. Wynikiem tej pracy jest dokładna analiza znalezionych podatności, ogólna ocena zagrożenia aplikacji oraz zalecenia naprawy.

Jakie narzędzia oraz metody najczęściej wykorzystują pentesterzy podczas testowania aplikacji webowych?

Nie będę ukrywać, że narzędziem numer 1 jest Google. Podobnie jak programiści nie musimy wymyślać koła na nowo, tylko korzystamy i czerpiemy inspiracje z prac i narzędzi innych pentesterów. Musimy być także na bieżąco z nowymi podatnościami, włączając w to błędy znalezione na komercyjnych komponentach aplikacji.

Testując aplikacje, natrafiamy na niezliczoną ilość technologii, frameworków, komponentów. To, że jakaś technologia jest dla nas nowa czy widzimy ją po raz pierwszy, nie jest wymówką, aby nie dowieźć pełnego pentestu, tylko jest motywacją do znalezienia nowych dla nas podatności. Dlatego ważne jest w naszej pracy robienie notatek i ciągła nauka.

Do tego dodam, że w testowaniu aplikacji webowych nie da się nie korzystać z proxy między przeglądarką a serwerem, który umożliwia podgląd komunikacji między nimi. Proxy takie jak BurpSuite dostarczają narzędzia nie tylko do przeglądu komunikacji, ale także do jej modyfikacji, spreparowania, czy ataków typu fuzzing.

Od czego zaczyna się profesjonalny test penetracyjny aplikacji? Które elementy są istotne dla skutecznego pentestu, a które bywają często pomijane lub niedoceniane przez firmy?

Klient zamawiający test penetracyjny powinien mieć świadomość tego, że po takim teście trzeba będzie wyciągnąć wnioski i naprawić błędy. My zazwyczaj nie ingerujemy w kod aplikacji, my znajdujemy błędy. Dlatego klient powinien przygotować się na omówienie wyników z programistami i dać im czas na ewentualne naprawy.

Oprócz tego, ważna jest komunikacja po stronie klienta, ponieważ zamawiając test penetracyjny, nie powinniśmy być zostawieni „sami sobie”, ale powinniśmy współpracować na rzecz bezpieczeństwa.

Podczas pentestu kontaktujemy się z osobą odpowiedzialną po stronie klienta, aby poinformować o przeszkodach, zapytać o funkcjonalności, czy, wedle żądania, na bieżąco zdawać raport o znalezionych podatnościach. Podsumowując, zamawiając pentest, firmy powinny przygotować zasób czasu także po swojej stronie.

W jaki sposób firma powinna przygotować się do testów penetracyjnych swoich aplikacji, aby osiągnąć najlepsze efekty współpracy z pentesterem? Czy są tutaj błędy, których szczególnie warto unikać?

Przede wszystkim test penetracyjny powinien być krokiem zaraz po testowaniu QA. Do testów bezpieczeństwa potrzebujemy stabilnej aplikacji wolnej od najprostszych błędów. Mogłabym przytoczyć tutaj bardzo dużo anegdotek o tym, jak nie mogłam rozpocząć testu przez brak działających kont, lub jak w połowie testu zaczęłam nagle być blokowana przez firewall.

Każdy dzień bezproblemowego testu jest ważny, ponieważ po napisaniu raportu pentester przechodzi zazwyczaj do innego klienta na kolejny test, aby utrzymać ciągłość pracy. W momencie, gdy takie problemy następują, czekając na ich rozwiązanie, staramy się kontynuować test w miarę możliwości. Na przykład gdy nie mogę się zalogować, to zaczynam test od poziomu użytkownika nieuwierzytelnionego.

Jakie podatności bezpieczeństwa w aplikacjach webowych są obecnie najczęstsze? Czy profil tych zagrożeń zmienia się wraz z rozwojem technologii, np. chmurowych?

W temacie najczęściej występujących podatności mówi się o OWASP Top 10, którym jest dokument przedstawiający 10 najczęściej występujących krytycznych podatności. Nie mówimy tutaj zatem o pomniejszych błędach, które same w sobie nie prowadzą do na przykład włamań czy kradzieży danych. Wyróżniają się tam błędy w autoryzacji i uwierzytelnieniu, czyli wszystko to, co jest związane z logowaniem do aplikacji i uprawnieniach użytkowników. Jako konsekwencje takich podatności w najgorszych przypadkach mówimy o przejęciu kont użytkowników na masową skalę.

Profil tych zagrożeń zmienia się, powiedziałabym, że ze względu na budowę dobrych praktyk. Na przykład w najnowszych frameworkach do budowania frontendu aplikacji na próżno jest szukać błędów typu wstrzyknięcie kodu JavaScript (chociaż nie mówię, że to nigdy już nie będzie możliwe).

Z drugiej strony, w obecnych czasach aplikacje webowe jako nieodłączny element naszego życia są coraz bardziej liczne i coraz bardziej zaawansowane. W momencie pisania odpowiedzi do tego wywiadu mam w tle otwarte 24 różne strony w przeglądarce. Jako użytkowniczka internetu nie mogę się bać, że na każdej z tych stron czeka na mnie jakieś zagrożenie.

Które podatności uważa Pani za najbardziej niebezpieczne z perspektywy konsekwencji biznesowych? Jak poważne mogą być skutki udanego ataku wykorzystującego takie luki?

Najpoważniejsze konsekwencje niesie za sobą na pewno zdalne wykonanie kodu (RCE). Skutki pomyślnego RCE różnią się w zależności od zabezpieczeń (przykładowo jeśli implementujemy zasadę Defence in Depth), ale w najgorszym możliwym wypadku mówimy o przejęciu kontroli nad aplikacją czy systemem, co może być użyte do sabotażu firmy i paraliżu jej działalności.

Nie można również dopuścić do wycieku danych wrażliwych. Zdarzało się, że w mediach czytaliśmy o wyciekach z jakiejś firmy, gdzie tak naprawdę to był zbiór informacji publicznie dostępnych. Także dane o działalności firmy i dane identyfikujące użytkowników to jest taki zasób, który nigdy nie powinien trafić w ręce przestępców.

Kiedy mówimy o skutkach pomyślnych ataków zawsze jest mowa o szkodach wizerunkowych i finansowych związanych z karami za wycieki. Sama obsługa tak dużego incydentu zakłóci normalne funkcjonowanie firmy nawet na kilka miesięcy.

Czy istnieją rodzaje aplikacji webowych szczególnie podatne na ataki – np. CRM-y, ERP czy platformy e-commerce? Jeśli tak, dlaczego właśnie one?

Ataków samych w sobie można się spodziewać w każdej aplikacji, ponieważ wystarczy jeden błąd do pełnej kompromitacji. Odpowiadając na to pytanie w kontekście, jakie oprogramowanie może mieć najwięcej tych luk – na pewno takie, które nie przeszło wyczerpującego procesu QA. Niekiedy błąd programisty czy projektowanie aplikacji „na szybko” prowadzi do błędu zagrażającemu bezpieczeństwu danych i użytkowników.

Jak często powinno się przeprowadzać testy penetracyjne aplikacji webowych, aby utrzymać wysoki poziom bezpieczeństwa? Co przede wszystkim wpływa na częstotliwość takich testów?

Znaczenie ma tutaj sektor firmy – czy to jest projekt rządowy, czy e-commerce, finansowy itd. Przykładowo standardy branżowe dla sektora finansowego nakładają obowiązek testowania aplikacji co najmniej raz na rok.

Z perspektywy osoby wykonującej taki test, poza jego regularnością najważniejszy jest powód podejścia do testu. Lepiej jest umówić test penetracyjny przed wdrożeniem ważnej funkcjonalności lub ogólnie przed większymi aktualizacjami. Wtedy to ma sens, bo jest dodawany nowy, nieprzetestowany kod, i trzeba go sprawdzić pod kątem wprowadzenia nowych podatności.

Jeśli aplikacja nie jest aktualizowana, to częstotliwość testów może być rzadsza, a nawet można wprowadzić testowanie automatyczne niewymagające tygodnia pracy pentestera. Automatyczne skanowanie podatności przeprowadza się głównie po to, aby wykryć proste podatności oraz żeby sprawdzić, czy komponenty, z których korzysta aplikacja, nie są przedawnione lub dziurawe.

Czy polskie firmy są świadome konieczności regularnego testowania bezpieczeństwa aplikacji webowych?

Osobiście nie działam na polskim rynku, więc nie mogę opowiedzieć o tym z własnego doświadczenia. Jednak jako część polskiego środowiska bezpieczników widzę, że poziom naszych profesjonalistów jest naprawdę wysoki i na arenie międzynarodowej nie mamy się czego wstydzić. Po niewielkiej ilości „wycieków” z polskich prywatnych firm można odnieść wrażenie, że z naszym cyfrowym bezpieczeństwem jest coraz lepiej.

Czy cyberprzestępcy stosują dziś bardziej zaawansowane metody ataków na aplikacje webowe niż kilka lat temu? Jakie nowe zagrożenia mogą pojawić się w tym obszarze w przyszłości?

Nowe zagrożenia są związane już częściej z nowymi technologiami, takimi jak LLM. W kontekście ataków na aplikacje webowe znajdujemy nowe luki, ale cały czas w znanym nam już zakresie gatunków tych podatności. Nawet jako doświadczona pentesterka muszę śledzić najnowsze metody ataków i nowe podatności, aby być w stanie je na bieżąco testować u klientów.

Przykładowo jeśli aplikacja korzysta z GraphQL, to muszę się zaznajomić z już istniejącymi podatnościami dla tej technologii, a potem próbować je znaleźć w aplikacji klienta. Pomimo tego, że wynajdujemy coraz to kreatywniejsze metody exploitacji, to kolejny raz zwrócę uwagę, że to najprostszy błąd może prowadzić do poważnych konsekwencji.

Trzeba pamiętać jednak o tym, że to, co my zabezpieczymy w aplikacji, to jedno, a to, co zrobi użytkownik na swoim koncie, to drugie. Jeśli użytkownik jest w kontakcie z oszustem, który go instruuje co ma kliknąć, to teoretycznie nie ma tu błędu bezpieczeństwa po stronie aplikacji. Przykładowo Browser-in-the-Middle jest relatywnie nową metodą ataku, ale nie targetuje konkretnej aplikacji webowej, a bezpośrednio użytkowników. Jako konsekwencja udanego ataku BitM jest kradzież sesji w tych aplikacjach, z których ofiara sama skorzysta.

Jakich najważniejszych rekomendacji bezpieczeństwa udzieliłaby Pani firmom rozwijającym aplikacje webowe, aby efektywnie chroniły się przed najczęstszymi zagrożeniami?

Moją radą jest to, żeby nie robić bezpieczeństwa zawsze po swojemu i na własną rękę. O ile zainteresowanie tematem cyberbezpieczeństwa samo w sobie jest godne pochwały, to w obecnych czasach jest to zbyt zaawansowany i szybko rozwijający się temat, żeby mieć pojęcie o wszystkim.

W miarę możliwości trzeba korzystać z wiedzy specjalistów, z gotowych narzędzi i bibliotek, czy z artykułów z gotowymi rozwiązaniami. Przykładowo bezcelowe byłoby pisanie własnych mechanizmów kryptograficznych, skoro istnieją biblioteki budowane i testowane przez społeczności.

Podobnie można powiedzieć o stawianiu własnego serwera pod aplikacje – obecne chmury są o wiele bezpieczniejszym i wygodniejszym rozwiązaniem. W razie wystąpienia zagrożeń nie jesteśmy wtedy zostawieni sami sobie, ale możemy skorzystać ze wsparcia dostawcy, czy po prostu zaktualizować dany komponent.