Krytyczna podatność usunięta jeszcze w trakcie testów — audyt bezpieczeństwa platformy rezerwacyjnej

Klient prowadzi platformę rezerwacyjną, przez którą klienci rezerwują usługi i przekazują swoje dane. Aplikacja rozwijała się szybko: API, panel, frontend, kolejne środowiska. Zespół chciał wiedzieć, jak system wygląda z perspektywy atakującego, zanim ktoś sprawdzi to za nich.

Przy takiej platformie każdy problem z bezpieczeństwem jest jednocześnie problemem prawnym (RODO) i wizerunkowym. Klient potrzebował nie listy ostrzeżeń ze skanera, ale oceny, co realnie grozi firmie i w jakiej kolejności to naprawiać.

Test black-box zamiast przeglądu kodu. Zacząłem od perspektywy zewnętrznego atakującego — bez dostępu do kodu i bez wiedzy o architekturze. To pokazuje, co faktycznie jest widoczne z internetu, a nie to, co zespół zakłada, że jest widoczne.

Rozpoznanie szersze niż przekazany zakres. Klient przygotował dla mnie środowisko testowe. Zanim zacząłem je testować, sprawdziłem, jakie jeszcze zasoby firmy są publicznie dostępne. Znalazłem środowisko, którego nie było w zakresie i o którego ekspozycji zespół nie wiedział — a które miało powiązania z produkcją. Uzgodniłem z klientem rozszerzenie testów, bo to tam znajdowało się jedno z najpoważniejszych ryzyk.

Krytyczne znalezisko zgłoszone od razu, nie w raporcie końcowym. Gdy wykryłem podatność krytyczną, nie czekałem do końca testów. Przekazałem ją zespołowi natychmiast, a poprawkę zweryfikowałem jeszcze w trakcie audytu.

Standard i skala zamiast opinii. Oparłem się na OWASP Top 10, OWASP ASVS 4.0 i metodyce PTES. Każde znalezisko ma wagę w pięciostopniowej skali — od krytycznej do informacyjnej — oraz ocenę wpływu na biznes. Dzięki temu zespół mógł zaplanować pracę, a nie tylko się przestraszyć.

Dobre praktyki też w raporcie. Opisałem nie tylko błędy, ale też to, co działało poprawnie. Szereg typowych klas ataków okazał się nieskuteczny, a konfiguracja serwerów w wielu miejscach była zrobiona dobrze. Zespół wiedział, czego nie ruszać przy poprawkach.

Nazwy klienta i szczegółów podatności celowo tu nie podaję — pozostają w raporcie przekazanym klientowi.

Testy trwały dwa tygodnie i objęły środowisko produkcyjne oraz testowe: rozpoznanie infrastruktury, API, uwierzytelnianie, kontrolę dostępu do zasobów, konfigurację serwerów i nagłówki bezpieczeństwa. Wynikiem był raport z podsumowaniem dla zarządu, opisem każdego znaleziska, oceną ryzyka i rekomendacjami uporządkowanymi według priorytetu.

Po oddaniu raportu konsultowałem z zespołem sposób wdrożenia poprawek.

• 15 znalezisk: 1 krytyczne, 2 wysokie, 3 średnie, 3 niskie i 6 informacyjnych.
• Podatność krytyczna została usunięta jeszcze w trakcie testów.
• Zespół dostał plan: najpierw konfiguracja produkcji i dostęp do środowiska testowego, potem kontrola dostępu w API i ograniczenie danych zwracanych przez endpointy.
• Wdrożenie poprawek przebiegło sprawnie — klient potwierdził to w pisemnej opinii o współpracy.