Test penetracyjny aplikacji webowej krok po kroku - etapy według OWASP WSTG

Test penetracyjny aplikacji webowej to nie jednorazowe "puszczenie skanera", tylko uporządkowany proces z jasnym początkiem i końcem. Zamawiający, który rozumie jego etapy, lepiej przygotuje środowisko, szybciej odpowie na pytania testera i dostanie raport, z którym da się pracować. Poniżej opisujemy testy penetracyjne krok po kroku - tak, jak prowadzi się je według OWASP Web Security Testing Guide (WSTG) i ram procesu z PTES.

Jeśli dopiero porównujesz oferty, zacznij od artykułu jak porównać oferty na testy penetracyjne. Czym test penetracyjny różni się od skanu i audytu, wyjaśniamy w artykule skan podatności a pentest i audyt.

Testy penetracyjne krok po kroku: 6 etapów

1. 01

   Zakres, zgoda i przygotowanie

   Cel testu, lista celów, zasady testów na piśmie, konta testowe dla każdej roli, okna czasowe i kontakt awaryjny.

2. 02

   Rozpoznanie

   Mapa aplikacji: funkcje, role, punkty wejścia, API, technologie i konfiguracja widoczna z zewnątrz.

3. 03

   Testy według WSTG

   Uwierzytelnianie, sesje, uprawnienia, walidacja danych, logika biznesowa i strona klienta - ręcznie, wspierane narzędziami.

4. 04

   Potwierdzenie i ocena

   Każda podatność potwierdzona bezpiecznym dowodem, łączenie słabości w scenariusze, ocena CVSS i kontekst biznesowy.

5. 05

   Raport i prezentacja

   Część dla zarządu, dowody techniczne, rekomendacje naprawy i omówienie wyników z zespołem.

6. 06

   Naprawy i retest

   Zespół usuwa podatności, a tester sprawdza każdą z nich ponownie i aktualizuje raport.

Podział na etapy pokrywa się z siedmioma sekcjami PTES (Penetration Testing Execution Standard): ustalenia przed testem, zbieranie informacji, modelowanie zagrożeń, analiza podatności, wykorzystanie podatności, działania po wykorzystaniu i raportowanie. W teście aplikacji webowej modelowanie zagrożeń i analiza podatności przeplatają się z testami, dlatego łączymy je w jeden etap.

Etap 1: zakres, zasady testów i przygotowanie

Bez pisemnej zgody właściciela systemu test penetracyjny niczym nie różni się od ataku - także w świetle przepisów karnych o nieuprawnionym dostępie do systemu informatycznego (art. 267-269b Kodeksu karnego). Dlatego pierwszy etap to dokumenty i ustalenia:

• cel testu - np. odbiór nowej aplikacji, wymóg klienta, przygotowanie do audytu, test po dużej zmianie,
• lista celów - adresy aplikacji, API, środowisko (testowe czy produkcyjne) i to, czego testować nie wolno,
• podejście - black box, grey box albo white box; dla aplikacji z logowaniem standardem jest grey box,
• zasady testów - kto po Twojej stronie podpisuje zgodę, okna czasowe, kontakt awaryjny, lista operacji zabronionych,
• konta testowe - najlepiej po dwa w każdej roli, z danymi, które można bezpiecznie zmieniać.

Nasze zasady pracy w trybie nieinwazyjnym są stałe dla każdego testu:

• Bez modyfikacji danych - nie zmieniamy danych, baz, plików ani kont użytkowników.
• Bez DoS i testów obciążeniowych - nie wykonujemy testów obciążeniowych ani ataków DoS/DDoS.
• Bez trwałych zmian - nie zostawiamy webshelli, backdoorów ani innych trwałych zmian w systemie.
• Bezpieczne Proof of Concept - podatność potwierdzamy minimalnym, bezpiecznym dowodem - bez wykorzystywania jej dalej, niż trzeba.
• Brute-force tylko za zgodą - próby odgadywania haseł - najwyżej 20 i wyłącznie za pisemną zgodą.

Etap 2: rozpoznanie aplikacji

Zanim tester zacznie szukać podatności, buduje mapę aplikacji. W WSTG odpowiadają temu kategorie zbierania informacji (WSTG-INFO) i konfiguracji (WSTG-CONF). Tester przechodzi przez aplikację w każdej roli, rejestruje żądania w narzędziu pośredniczącym (proxy), spisuje funkcje, formularze, parametry, punkty wejścia i wywołania API, rozpoznaje technologie oraz sprawdza, co aplikacja i serwer ujawniają o sobie z zewnątrz - nagłówki, komunikaty błędów, pliki pozostawione na serwerze, kopie zapasowe, panele administracyjne.

Dobra specyfikacja API (np. OpenAPI) i lista ról skracają ten etap i sprawiają, że czas testu idzie na testy, a nie na odgadywanie, co aplikacja potrafi.

Etap 3: testy według kategorii OWASP WSTG

OWASP WSTG w stabilnej wersji v4.2 dzieli testy aplikacji webowych na 12 kategorii. Trwają prace nad wersją 5.0, ale to v4.2 jest dziś punktem odniesienia w raportach i ofertach.

Kategorie mają różną wagę. Najwięcej czasu ręcznej pracy zajmują zwykle uwierzytelnianie, autoryzacja i logika biznesowa - bo tu leżą błędy, których nie wykryje żaden skaner. Klasyczny przykład to IDOR: zalogowany klient zmienia numer faktury w żądaniu i dostaje fakturę innego klienta. Kategoria błędów kontroli dostępu, do której należy, zajmuje pierwsze miejsce na liście OWASP Top 10:2025.

Narzędzia automatyczne - skanery aplikacji, fuzzery, narzędzia do testów TLS - wspierają testera w kategoriach, gdzie liczy się powtarzalność, np. w walidacji danych wejściowych. Ich wyniki są jednak punktem wyjścia, a nie ustaleniem do raportu.

Etap 4: potwierdzenie podatności i ocena ryzyka

Każde ustalenie trafia do raportu dopiero po potwierdzeniu - minimalnym, bezpiecznym dowodem, który pokazuje, że podatność istnieje i co da się dzięki niej osiągnąć. Na tym etapie tester łączy też słabości w scenariusze: komunikat ujawniający, czy login istnieje, brak limitu prób logowania i przewidywalny token resetu hasła osobno są drobne, a razem mogą dać przejęcie konta.

Powagę podatności ocenia się zwykle w skali CVSS. Aktualna wersja to CVSS 4.0, którą FIRST opublikował 1 listopada 2023 r., ale w raportach i bazach podatności nadal powszechnie używa się wersji 3.1. Dlatego w raporcie zawsze podajemy wersję skali i pełny wektor, a obok - ocenę kontekstową: jakie dane są zagrożone i kto może wykorzystać podatność.

Przykład demonstracyjny: podatność opisana w raporcie

Poniższy opis jest demonstracyjny - adresy i dane są fikcyjne i nie pochodzą z testu u żadnego klienta. Pokazuje, jak wygląda pojedyncze ustalenie z etapu 4: z oceną, dowodem i rekomendacją.

$ curl -s -X POST https://app.firma.example/api/auth/password-reset \
  -H "Host: atakujacy.example" \
  -H "Content-Type: application/json" \
  -d '{"email":"klient.b@firma.example"}'
HTTP/1.1 202 Accepted

Treść wiadomości odebranej na koncie testowym klient.b:
https://atakujacy.example/reset?token=[token jednorazowy]

Ocena bazowa CVSS 3.1 to 8.1 (High): atak przez sieć, bez uprawnień, wymaga jednego kliknięcia ofiary, a skutkiem jest pełny dostęp do jej konta. W ocenie kontekstowej priorytet rośnie, jeśli tą drogą da się przejąć konto administratora.

Etap 5: raport i prezentacja wyników

Raport to główny produkt testu. Powinien dać się przeczytać na dwóch poziomach: zarząd ma zrozumieć ryzyko w kilka minut, a zespół techniczny - odtworzyć każdy krok i naprawić błąd. Nasz raport składa się z części:

• Executive Summary - podsumowanie dla zarządu językiem biznesowym: najważniejsze ryzyka, ich skutki i priorytety.
• Część black box i grey box - wyniki testu bez dostępu i z kontami testowymi opisane rozdzielnie - widać, co grozi z zewnątrz, a co po zalogowaniu.
• Dowody techniczne - dosłowny wynik poleceń i zapytań, bez parafraz - Twój zespół może odtworzyć każdy krok.
• Rekomendacje naprawy - konkretna propozycja naprawy każdej podatności, a przy rewizji kodu - gotowa poprawka.
• Harmonogram remediacji - zalecane terminy usunięcia podatności według poziomu ryzyka.
• Wersje PL i EN - raport po polsku i angielsku - dla zespołów i zarządów międzynarodowych.

Po raporcie przychodzi prezentacja: omówienie wyników z zespołem technicznym i krótki briefing dla zarządu. To dobry moment na pytania o priorytety napraw i o to, które podatności wymagają zmian w architekturze, a nie tylko poprawki w kodzie.

Etap 6: naprawy i retest

Raport opisuje stan sprzed napraw. Dopiero retest potwierdza, że podatności usunięto skutecznie i że poprawki nie wprowadziły nowych błędów. Tester powtarza dowody z raportu dla każdej podatności i aktualizuje raport o wynik sprawdzenia. Przy błędach uprawnień warto też dodać automatyczne testy autoryzacji dla każdej roli - wtedy ten sam błąd nie wróci przy kolejnym wydaniu.

Co przygotować po swojej stronie

Krótka lista, która oszczędza najwięcej czasu w trakcie testu:

1. Osoba kontaktowa i kontakt awaryjny na czas testu.
2. Podpisane zasady testów i lista celów.
3. Konta testowe - po dwa w każdej roli - i dane, które można zmieniać.
4. Dokumentacja API (np. OpenAPI) i opis ról oraz najważniejszych procesów biznesowych.
5. Informacja dla dostawcy hostingu lub chmury, jeśli jego zasady wymagają zgłoszenia testu.
6. Decyzja, czy na czas testu dopuścić adresy testera w WAF - bez tego test sprawdzi głównie WAF, a nie aplikację.
7. Aktualna kopia zapasowa środowiska testowego, jeśli test ma objąć operacje zapisu.

Jak testujemy aplikacje webowe

Testujemy portale klientów, systemy transakcyjne, panele administracyjne i sklepy internetowe według OWASP WSTG v4.2, z oceną w CVSS i retestem poprawek. Zakres, sposób pracy z kontami i rolami, przykład opisu podatności i czynniki, od których zależy czas testu, opisujemy na stronie testy penetracyjne aplikacji webowych. Gdy aplikacja korzysta z API dla aplikacji mobilnej lub partnerów, zobacz też testy bezpieczeństwa API.