Co ujawnił pentest platformy online?

Case study SPIREE | test white-box platformy internetowej obsługującej konta użytkowników i operacje finansowe

W ramach autoryzowanego testu penetracyjnego sprawdziliśmy platformę internetową, w której ważne były zarówno dane użytkowników, jak i bezpieczeństwo funkcji administracyjnych. Test przeprowadziliśmy w formule white-box, co pozwoliło ocenić nie tylko zewnętrzny interfejs, lecz także API, mechanizmy dostępu, wybrane elementy środowiska chmurowego, repozytorium kodu i konfigurację środowiska testowego.

Co chcieliśmy zweryfikować?

Wspólnie z zespołem klienta określiliśmy zakres obejmujący główne obszary platformy. Sprawdziliśmy między innymi, czy:

• dostęp do danych i funkcji jest prawidłowo ograniczony,

• API wymaga właściwego uwierzytelnienia i egzekwuje uprawnienia,

• zasoby przechowujące dane nie są dostępne publicznie,

• sekrety i tokeny są bezpiecznie obsługiwane,

• konfiguracja sesji i uwierzytelniania wspiera ochronę kont,

• środowisko stagingowe nie udostępnia niepotrzebnych funkcji diagnostycznych.

Co znaleźliśmy?

Test ujawnił 16 podatności i słabości: jedną krytyczną, pięć o wysokim, trzy o średnim i pięć o niskim poziomie ryzyka, a także dwa ustalenia informacyjne.

Najpoważniejszy problem dotyczył kontroli dostępu: możliwe było uzyskanie nieuprawnionego dostępu do wszystkich rozmów użytkowników z zespołem wsparcia.

Zidentyfikowaliśmy również pięć problemów o wysokim poziomie ryzyka:

• możliwość ominięcia warstwy ochronnej i bezpośredniego dotarcia do API,

• brak kontroli uprawnień na wybranych endpointach administracyjnych,

• publiczną dostępność zasobu przechowującego dane w chmurze,

• ujawnienie danych administracyjnych bez wymaganego uwierzytelnienia,

• sekrety i tokeny zapisane w repozytorium.

Pozostałe ustalenia obejmowały:

• Średnie ryzyko: ujawnione mapy źródłowe, niebezpieczną konfigurację ciasteczek sesyjnych i sygnały potencjalnego ryzyka w łańcuchu dostaw.

• Niskie ryzyko: brak walidacji adresów wypłat, niespójne egzekwowanie uwierzytelniania dwuskładnikowego, brak części nagłówków bezpieczeństwa, nadmierne ujawnianie danych i użycie podatnej wersji biblioteki frameworka.

• Ustalenia informacyjne: dostępne endpointy diagnostyczne w środowisku stagingowym oraz podatne zależności zewnętrzne.

Dlaczego te ustalenia miały znaczenie?

Kilka problemów dotyczyło granic dostępu: kto może czytać rozmowy, pobierać dane lub korzystać z funkcji administracyjnych. Inne wiązały się z ochroną kont i sekretów albo z tym, czy zasoby i interfejsy są dostępne tylko dla uprawnionych osób i systemów.

Połączenie takich słabości może zwiększać ryzyko naruszenia poufności danych, nieuprawnionych działań w panelach administracyjnych oraz wykorzystania przejętych tokenów lub błędów w konfiguracji. Raport opisywał ustalenia wraz z poziomem ryzyka, aby zespół mógł ustalić kolejność działań naprawczych.

Co daje test white-box?

Test white-box pozwala badać rozwiązanie z dostępem do dodatkowych informacji o jego budowie i działaniu. Dzięki temu można sprawdzić nie tylko to, co widać z zewnątrz, ale również mechanizmy autoryzacji, API, konfigurację oraz wybrane elementy kodu i zależności.

W tym projekcie takie podejście pomogło wykryć problemy w różnych warstwach platformy — od kontroli dostępu do rozmów użytkowników, przez endpointy administracyjne, po sekrety w repozytorium i zasoby w chmurze.

Wnioski

Najpoważniejsze ryzyka nie zawsze wynikają z jednej skomplikowanej podatności. Czasem krytyczne znaczenie ma brak kontroli dostępu w miejscu, które łączy dane użytkowników z funkcjami operacyjnymi platformy. Dlatego test powinien obejmować przepływy danych i uprawnień w całym rozwiązaniu, a nie tylko pojedynczy ekran lub adres URL.

SPIREE prowadzi testy penetracyjne aplikacji, API i infrastruktury. Zakres dobieramy do architektury produktu oraz tego, co klient chce zweryfikować przed wdrożeniem, audytem lub kolejnym etapem rozwoju.

Chcesz sprawdzić, jak Twoja platforma zachowuje się z perspektywy potencjalnego atakującego? Porozmawiajmy o zakresie testu.

Wersja nie przypisuje klientowi wdrożenia poprawek ani pozytywnego wyniku retestów — nie ma tych informacji w przekazanym podsumowaniu testu.