Dwie krytyczne podatności wykryte, zanim znaleźli je atakujący — audyt bezpieczeństwa platformy SaaS

Klient to startup rozwijający platformę SaaS. Łączy się ona ze stronami WordPress swoich użytkowników przez własną wtyczkę i wykonuje na nich operacje w ich imieniu. Taki model oznacza, że problem w platformie nie dotyczy jednej firmy, lecz każdej podłączonej strony.

Zespół wiedział o części problemów i część już poprawił. Potrzebował niezależnej oceny, czy platforma jest gotowa na dalszy rozwój i pozyskiwanie klientów.

Trzy powierzchnie ataku, jeden audyt. Testowałem aplikację webową, API i wtyczkę WordPress razem. Osobno każda z nich mogła wyglądać poprawnie. Ryzyko pojawiało się na styku — tam, gdzie platforma ufa wtyczce, a wtyczka platformie.

Weryfikacja, nie zaufanie. Przed audytem zespół zgłosił, że jeden z poważnych problemów jest już naprawiony. Nie przyjąłem tego jako faktu, tylko sprawdziłem. Poprawkę dało się obejść, a problem pozostał krytyczny. To jedno z najważniejszych znalezisk całego audytu.

Ryzyko w języku biznesu. Przy każdym znalezisku opisałem nie tylko technikę, ale skutek dla firmy: dostęp do danych klientów i obowiązki wynikające z RODO, przejęcie kont, a także bezpośrednie koszty finansowe. Jeden z problemów o średniej wadze technicznej mógł generować realne rachunki po stronie klienta — dlatego dostał osobne miejsce w rekomendacjach.

Błędy projektowe oddzielone od błędów implementacji. Część problemów dało się usunąć jedną poprawką. Inne wynikały z przyjętej architektury i wymagały decyzji produktowej. Rozdzieliłem je, żeby zespół wiedział, co naprawić od razu, a co zaplanować.

Jasna rekomendacja. Nie zostawiłem klienta z samą listą. Raport kończy się oceną gotowości platformy: przed wdrożeniem poprawek krytycznych nie rekomendowałem dalszego wykorzystania produkcyjnego. Zaleciłem też ponowny test po poprawkach.

Nie podaję nazwy klienta ani szczegółów podatności — te informacje pozostają w raporcie.

Testy trwały dwa tygodnie w modelu black-box, według OWASP, OWASP ASVS, OSSTMM i PTES. Objęły rozpoznanie infrastruktury, uwierzytelnianie i sesje, uprawnienia, API, integracje zewnętrzne, konfigurację serwerów oraz bezpieczeństwo wtyczki WordPress.

Wtyczce poświęciłem osobną uwagę. To ona jest instalowana na stronach klientów końcowych, więc każda jej słabość staje się słabością cudzej strony. Oprócz podatności oceniłem, jak można ją utwardzić, żeby ograniczyć skutki ewentualnego błędu po stronie platformy.

Raport zawiera podsumowanie dla zarządu, mapę infrastruktury z rozpoznania, opis znalezisk z oceną wpływu na biznes oraz rekomendacje w kolejności wdrażania.

• 13 znalezisk: 2 krytyczne, 1 wysokie, 3 średnie i 7 informacyjnych.
• Jedna z podatności krytycznych dotyczyła poprawki, którą zespół uważał za skuteczną — bez weryfikacji pozostałaby niezauważona.
• Zidentyfikowałem ryzyko bezpośrednich kosztów finansowych, niewidoczne w standardowej ocenie technicznej.
• Klient dostał jednoznaczną rekomendację, plan poprawek według priorytetów i zalecenie ponownego testu.