Poniższe case study jest scenariuszem ilustracyjnym opartym na typowym przebiegu naszych projektów pentestowych. Dane, branża i szczegóły techniczne zostały zanonimizowane i zmienione tak, aby nie wskazywały żadnego klienta.
Kontekst i cel testu
Firma usługowa z sektora B2B udostępnia klientom panel webowy do obsługi zamówień i dokumentów. Przed planowanym wdrożeniem nowych funkcji zarząd chciał zweryfikować, czy dane klientów są właściwie odseparowane, a aplikacja odporna na najczęstsze ataki. Wybrano test penetracyjny aplikacji webowej w modelu grey box — z kontami testowymi dla każdej roli, ale bez dostępu do kodu źródłowego.
Zakres i metodyka
- aplikacja webowa (panel klienta + panel administracyjny) oraz API, z którego korzysta frontend,
- testy ręczne wg OWASP WSTG z weryfikacją kategorii OWASP Top 10,
- okno testowe uzgodnione na środowisku stagingowym z danymi testowymi,
- czas trwania: 8 dni roboczych + raport + retest po poprawkach.
Najważniejsze ustalenia
| Podatność | Ocena CVSS | Ryzyko |
|---|---|---|
| IDOR — dostęp do dokumentów innych klientów po zmianie identyfikatora w żądaniu API | 8.1 (wysokie) | wyciek danych kontraktowych dowolnego klienta |
| Brak rate limitingu na logowaniu i resetowaniu hasła | 6.5 (średnie) | ataki słownikowe na konta użytkowników |
| Sesja nie wygasa po zmianie hasła | 5.4 (średnie) | utrzymanie dostępu przez przejętą sesję |
| Brak nagłówków bezpieczeństwa (CSP, HSTS) | 3.7 (niskie) | ułatwione ataki XSS/downgrade |
Jak wyglądała eksploatacja IDOR?
Aplikacja poprawnie weryfikowała, czy użytkownik jest zalogowany, ale nie sprawdzała, czyj zasób pobiera. Po zalogowaniu na konto testowe wystarczyło zmienić identyfikator dokumentu w żądaniu API, aby pobrać plik należący do innego klienta. To klasyczny przykład luki, której automatyczny skaner podatności nie wykryje — wymaga zrozumienia logiki biznesowej aplikacji.
Rezultat i retest
Raport zawierał opis każdej podatności ze scenariuszem ataku, oceną CVSS i konkretną rekomendacją naprawczą. Zespół deweloperski klienta wdrożył poprawki w ciągu trzech tygodni (centralna kontrola autoryzacji na poziomie API, rate limiting, unieważnianie sesji, nagłówki bezpieczeństwa). Retest potwierdził skuteczność wszystkich poprawek — żadna z podatności nie była już możliwa do wykorzystania.
Wnioski dla Twojej firmy
- Najpoważniejsze luki dotyczą zwykle autoryzacji i logiki biznesowej — nie wykryje ich skaner, tylko ręczny test.
- Model grey box daje najlepszy stosunek pokrycia do kosztu — tester widzi aplikację tak, jak widzi ją klient z legalnym kontem.
- Retest powinien być częścią projektu — poprawka niezweryfikowana to poprawka niepewna.
Zastanawiasz się, ile kosztowałby taki test dla Twojej aplikacji? Zobacz nasz przewodnik po cenach pentestów albo zapytaj o wycenę — wstępna konsultacja jest bezpłatna.
Przeczytaj także
Autor
Dominik Rulkiewicz
IT Security Manager · Octopus Lab
Ekspert cyberbezpieczeństwa z ponad 10-letnim doświadczeniem w sektorach regulowanych (ubezpieczenia, farmacja, logistyka). Process Owner ds. zarządzania podatnościami i hardeningu w Grupie ERGO, Audit Lead ISO 27001. Specjalizuje się w testach penetracyjnych, audytach bezpieczeństwa oraz zgodności z NIS2, DORA, ISO 27001 i RODO.
Certyfikaty: ISC2 CC · Cybersecurity Blue Team (Uniwersytet Jagielloński) · ITIL v4 · Microsoft Azure (AZ-900)
