Jak testujemy: nasza metodyka testów penetracyjnych

Podejście manualne, bo skaner widzi tylko połowę obrazu

Skaner jest doskonały, jeśli chodzi o szerokość: rozpoznaje oprogramowanie, wskazuje brakujące nagłówki i dopasowuje znane sygnatury CVE w tysiącach żądań. Jest jednak słaby w ocenie sytuacji. Nie rozpozna, że `200 OK` zwracający fakturę innego najemcy to krytyczna luka w kontroli dostępu, bo składniowo wszystko wygląda poprawnie. Nadużycia logiki biznesowej, granice autoryzacji, łańcuchy luk o niskiej istotności i wyścigi (race conditions) mieszczą się dokładnie w tym martwym polu, którego automat nie potrafi zrozumieć.

Automatyzacji używamy świadomie — Burp Suite Professional, nuclei i dedykowane skrypty — jako wzmocnienia pokrycia i kontroli regresji, nigdy jako samego testu. To tester stawia hipotezy, manipuluje stanem aplikacji i potwierdza realny wpływ. Na tym polega różnica między „narzędzie to zgłosiło” a „udowodniliśmy to”.

• Skanery znajdują znane wzorce; człowiek znajduje logikę, która nigdy nie była wzorcem.
• Autoryzacja, wielodostępność i nadużycia procesów są praktycznie niewidoczne dla narzędzi sygnaturowych.
• Automatyzacja daje pokrycie i szybkość; testy manualne dają dowód i kontekst.

Faza 1 — Przed rozpoczęciem: zakres, autoryzacja, zasady współpracy

Zanim wyślemy pierwszy pakiet, musi istnieć podpisana autoryzacja. Na tym etapie uzgadniamy dokładny zakres (hosty, domeny, aplikacje i API objęte testem oraz jawne wyłączenia), okno testowe, poziomy kont, na których testujemy, oraz kontakty do eskalacji. Zasady współpracy (Rules of Engagement) spisujemy: co jest dozwolone, co jest wykluczone (na przykład brak ataków typu DoS i brak destrukcyjnych ładunków na danych produkcyjnych), adresy źródłowe do dodania na listę dozwolonych oraz kanał awaryjny, gdy podejrzewamy realne włamanie lub wyjątkowo kruchy system.

Cel definiujemy w języku klienta — ochrona danych osobowych, zapobieganie przejęciu kont, spełnienie wymagania ISO 27001 lub SOC 2 — aby wysiłek skierować tam, gdzie faktycznie leży ryzyko biznesowe, a nie rozłożyć go równomiernie na szum.

• Podpisana autoryzacja i spisany zakres przed wygenerowaniem jakiegokolwiek ruchu.
• Zasady współpracy: dozwolone techniki, wyłączenia, godziny testów, ścieżka powiadamiania.
• Imienne kontakty awaryjne i warunek wstrzymania prac przy sytuacji wysokiego ryzyka.

Faza 2 — Rozpoznanie i mapowanie

Zanim zaczniemy sondować powierzchnię ataku, budujemy jej pełny obraz. Po rozpoznaniu pasywnym (DNS, logi Certificate Transparency, publiczny kod i metadane) następuje aktywne mapowanie: enumeracja hostów, portów i usług, przejście aplikacji oraz skatalogowanie każdego endpointu, parametru, przepływu uwierzytelniania i roli. Jest to zgodne z OWASP WSTG w obszarach Information Gathering (WSTG-INFO) i Configuration Management (WSTG-CONF).

Produktem tej fazy jest wewnętrzna mapa: co komu ufa, gdzie dane przekraczają granicę i które endpointy obsługują wrażliwe obiekty. Test, którego nigdy nie pomyśleliśmy uruchomić, to luka, której nigdy nie znajdziemy — dlatego pokrycie powierzchni traktujemy jako pełnoprawną miarę jakości.

Faza 3 — Modelowanie zagrożeń

Mając mapę, myślimy jak napastnik z celami. Identyfikujemy istotne aktywa, granice zaufania wokół nich oraz realistycznych aktorów zagrożenia — nieuwierzytelnionego użytkownika z internetu, klienta o niskich uprawnieniach, złośliwego insidera. Enumerujemy przypadki nadużyć dla każdego komponentu (w stylu STRIDE: spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) i szeregujemy je według prawdopodobieństwa i wpływu biznesowego.

Powstaje z tego priorytetyzowany plan testów. Zamiast testować wszystko powierzchownie, największy manualny wysiłek kierujemy tam, gdzie udany atak wyrządza najwięcej szkód — przepływy płatności, uwierzytelnianie, dostęp do danych w środowisku wielodostępnym i funkcje administracyjne.

Faza 4 — Testy manualne i bezpieczna eksploatacja

To rdzeń pracy. Realizujemy plan w oparciu o przypadki testowe OWASP WSTG i kategorie OWASP Top 10, weryfikując każdą potencjalną lukę ręcznie. Uwierzytelnianie i zarządzanie sesją (WSTG-ATHN, WSTG-SESS), autoryzacja oraz IDOR/BOLA (WSTG-ATHZ), obsługa danych wejściowych — injection, SQLi, XSS — (WSTG-INPV), logika biznesowa (WSTG-BUSL) i kryptografia (WSTG-CRYP) są pokrywane systematycznie i odnoszone do kontroli ASVS tam, gdzie przydatne jest spojrzenie na dojrzałość.

Eksploatacja jest zawsze bezpieczna i proporcjonalna. Lukę dowodzimy minimalnym działaniem potrzebnym do jej wykazania: odczytaniem jednego rekordu, do którego nie powinniśmy mieć dostępu, uzyskaniem nieszkodliwego tokenu dowodowego, pokazaniem kontrolowanego `alert(document.domain)` przy XSS. Nigdy nie wynosimy prawdziwych danych klientów, nie uruchamiamy destrukcyjnych ładunków ani nie obniżamy dostępności. Każdy krok jest logowany wraz z żądaniami i odpowiedziami ze znacznikami czasu, aby znalezisko dało się w pełni odtworzyć.

• Systematyczne pokrycie kategorii OWASP WSTG i OWASP Top 10.
• Dowód wpływu najmniej inwazyjnym działaniem — bez kradzieży danych i bez destrukcji.
• Pełny materiał dowodowy żądań/odpowiedzi do odtworzenia co do bajta.

Faza 5 — Po eksploatacji: pomiar realnego wpływu

Zdobycie przyczółka to nie jest jeszcze znalezisko — znaleziskiem jest to, co ten przyczółek oznacza. W kontrolowany sposób i ściśle w granicach Rules of Engagement oceniamy, jak daleko sięga potwierdzona luka: jakie dane stają się czytelne, czy uprawnienia da się eskalować, czy jedna słabość łączy się w łańcuch z inną i prowadzi do najcenniejszego aktywa. Odbite XSS to jedno; odbite XSS, które kradnie sesję administratora i pozwala przejąć całego najemcę, to zupełnie inna rozmowa biznesowa.

Określamy zasięg rażenia, nigdy nie realizując go destrukcyjnie. Wynikiem jest opis wpływu w prostym języku biznesu — „nieuwierzytelniony napastnik mógłby wyliczyć i odczytać faktury każdego klienta” — który potrafi ocenić także osoba nietechniczna.

Faza 6 — Ocena ryzyka według CVSS v3.1

Każde znalezisko otrzymuje bazową ocenę CVSS v3.1 wraz z pełnym wektorem, dzięki czemu ocena jest przejrzysta i niezależnie weryfikowalna, a nie subiektywną etykietą. Oceniamy Attack Vector, Attack Complexity, Privileges Required, User Interaction, Scope oraz wpływ na Confidentiality/Integrity/Availability, a tam, gdzie to zasadne, dodajemy metryki Temporal i Environmental, aby odzwierciedlić rzeczywisty kontekst klienta.

CVSS to punkt wyjścia, a nie cała historia. Wartość liczbową uzgadniamy z rzeczywistym wpływem biznesowym i realną eksploatowalnością, więc technicznie „średnia” luka umożliwiająca przejęcie konta zostaje w narracji podniesiona i odpowiednio spriorytetyzowana. Raport szereguje problemy tak, by wysiłek naprawczy podążał za realnym ryzykiem.

Przykładowe znalezisko poglądowe — IDOR w API faktur

Poniższy przykład ma charakter poglądowy i pokazuje sposób, w jaki dokumentujemy znalezisko. Nie dotyczy realnego klienta ani żadnego rzeczywistego systemu.

Tytuł: Insecure Direct Object Reference (IDOR) ujawniający faktury między najemcami. Istotność: Wysoka — CVSS v3.1 8.1 (wektor AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N). Kategoria: OWASP Top 10 A01:2021 Broken Access Control; WSTG-ATHZ-04 (Insecure Direct Object References).

Co znaleźliśmy: endpoint `GET /api/v2/invoices/{id}` zwracał obiekty faktur po sekwencyjnym identyfikatorze całkowitym i autoryzował żądanie wyłącznie na podstawie ważnej sesji, nigdy nie sprawdzając, czy faktura należy do najemcy wywołującego. Uwierzytelnieni jako użytkownik o niskich uprawnieniach w Najemcy A, zmieniliśmy `{id}` z naszego `50432` na `50431` i otrzymaliśmy fakturę innej organizacji — nazwę klienta, adres rozliczeniowy, pozycje i kwotę. Inkrementacja identyfikatora pozwalała przejść całą tabelę.

Wpływ biznesowy: każdy uwierzytelniony klient mógł wyliczyć i odczytać wszystkie faktury we wszystkich najemcach — masowe naruszenie poufności danych osobowych i handlowych, z wyraźnym ryzykiem naruszenia RODO oraz konsekwencjami kontraktowymi i reputacyjnymi.

Naprawa: wymuszenie autoryzacji na poziomie obiektu po stronie serwera dla każdego żądania — weryfikacja, że `tenant_id` żądanej faktury odpowiada najemcy uwierzytelnionego podmiotu przed jej zwróceniem, oraz zwracanie `404` (a nie `403`), by nie potwierdzać istnienia zasobu. Zastąpienie sekwencyjnych identyfikatorów całkowitych nieodgadywalnymi UUID jako obrona w głąb oraz dodanie automatycznego testu kontroli dostępu do potoku CI, aby regresja nie mogła po cichu wrócić.

• Istotność: Wysoka — CVSS v3.1 8.1, wektor AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N.
• Przyczyna źródłowa: uwierzytelnianie obecne, brak autoryzacji na poziomie obiektu.
• Naprawa: serwerowe sprawdzenie własności najemcy + UUID + test regresji kontroli dostępu w CI.

Faza 7 — Raport, retest i zapewnienie jakości

Raport jest produktem. Otwiera go streszczenie dla zarządu, po którym następują znaleziska techniczne — każde z oceną i wektorem CVSS, krokami odtworzenia, dowodami ze znacznikami czasu, wpływem biznesowym i konkretną rekomendacją naprawy — nie „załatajcie to”, lecz konkretną kontrolą do wdrożenia. Znaleziska są uszeregowane tak, aby pierwsza naprawa usuwała najwięcej ryzyka.

Jakość egzekwujemy przed dostarczeniem: każde znalezisko jest weryfikowane przez drugiego testera, który niezależnie je odtwarza — tak utrzymujemy liczbę fałszywych alarmów bliską zeru, bo nie raportujemy tego, czego nie potrafimy udowodnić. Po wdrożeniu poprawek wykonujemy bezpłatny retest, potwierdzając, że każda naprawa faktycznie zamyka problem i nie wprowadza regresji, a raport wydajemy ponownie ze zaktualizowanym statusem. Całość jest objęta NDA; dowody i dane klienta szyfrujemy w spoczynku, kontrolujemy do nich dostęp, przechowujemy wyłącznie przez uzgodniony czas i bezpiecznie niszczymy zgodnie z harmonogramem.

• Weryfikacja drugiego testera z niezależnym odtworzeniem — liczba fałszywych alarmów bliska zeru.
• Konkretne, uszeregowane rekomendacje naprawy zamiast ogólnych porad.
• Bezpłatny retest po naprawach; NDA, szyfrowanie i planowe niszczenie danych na każdym etapie.

FAQ