Test penetracyjny aplikacji internetowej nie zaczyna się od skanera. Zaczyna się od zgody, zakresu i odpowiedzialności. Bez tego łatwo pomylić profesjonalny test z chaotycznym „sprawdźmy, czy coś znajdzie”. W najlepszym razie powstanie słaby raport. W najgorszym ktoś przeciąży produkcję albo dotknie danych, których nie powinien ruszać.

Aplikacje webowe mają dziś logowanie, role użytkowników, płatności, API, formularze, panele administracyjne i integracje. Test powinien sprawdzać te miejsca w kontekście działania firmy, zamiast ograniczać się do listy technicznych podatności.

Kiedy warto zrobić test?

przed uruchomieniem aplikacji z kontami użytkowników lub płatnościami,
po większej przebudowie logowania, uprawnień albo API,
przed integracją z systemem CRM, ERP, płatnościami lub zewnętrznym dostawcą danych,
gdy aplikacja przetwarza dane osobowe, dokumenty lub informacje finansowe,
po incydencie albo podejrzeniu, że dostęp był źle skonfigurowany.

Nie każda strona-wizytówka potrzebuje pełnego pentestu. Ale jeśli użytkownik może się zalogować, przesłać dane, zapłacić albo zobaczyć cudze informacje, zwykła checklista bezpieczeństwa przestaje wystarczać.

Zakres musi być konkretny

Dobry zakres testu mówi, które domeny, środowiska, adresy IP, role, konta testowe i funkcje wolno badać. Powinien też wskazać godziny testów, limity obciążenia, kontakt awaryjny i zakazane działania. To chroni obie strony.

Warto przygotować konta o różnych rolach: zwykły użytkownik, klient firmowy, administrator, operator, sprzedawca. W aplikacjach webowych wiele problemów siedzi w logice uprawnień: użytkownik widzi cudzy rekord, API zwraca za dużo danych, panel pozwala wykonać akcję bez właściwej roli.

Co powinno znaleźć się w teście aplikacji webowej?

logowanie, reset hasła, sesje, ciasteczka i wylogowanie,
kontrola dostępu do zasobów, paneli i endpointów API,
walidacja danych wejściowych i odporność na typowe ataki webowe,
upload plików, formularze, płatności i integracje,
konfiguracja nagłówków, CORS, błędy, logi i ujawnianie informacji.

OWASP Web Security Testing Guide jest dobrym punktem odniesienia, bo porządkuje testy według obszarów aplikacji. Nie oznacza to jednak, że każdy projekt potrzebuje identycznej liczby prób. Sklep, panel SaaS i prosta aplikacja rezerwacyjna mają inne ryzyka.

Skaner pomaga, ale nie myśli za testera

Automatyczne narzędzia potrafią znaleźć część problemów: znane podatności, brakujące nagłówki, błędy konfiguracji, stare biblioteki, prostsze błędy wejścia. Gorzej radzą sobie z logiką biznesową. Nie wiedzą, że użytkownik A nie powinien widzieć faktury użytkownika B albo że kupon rabatowy nie może być użyty dziesięć razy przez zmianę parametru.

Dlatego raport oparty wyłącznie na skanie jest zwykle za płytki. Ręczne sprawdzenie ścieżek użytkownika, ról i danych jest najbardziej wartościową częścią testu.

Jak powinien wyglądać raport?

Raport ma być użyteczny dla zespołu, który naprawia błędy. Dobre zgłoszenie zawiera opis ryzyka, kroki odtworzenia, zrzuty lub żądania HTTP bez ujawniania sekretów, wpływ na biznes, priorytet i rekomendację naprawy. Samo „high severity” nie wystarczy.

Po poprawkach potrzebny jest retest. Inaczej nie wiadomo, czy błąd zniknął, czy tylko przeniósł się w inne miejsce.

UK i projekty regulowane

Przy projektach publicznych, krytycznych lub formalnie wymagających określonego poziomu assurance trzeba sprawdzić, czy potrzebny jest dostawca z odpowiednim uznaniem, na przykład w schemacie CHECK opisanym przez NCSC. Dla małej firmy prywatnej taki poziom może być przesadą, ale sama zasada zostaje ta sama: zakres, uprawnienie, metodologia i raport muszą być jasne.

Test penetracyjny ma dać konkretną listę ryzyk do naprawy. Jeśli kończy się tylko ogólnym PDF-em i brakiem rozmowy z wykonawcami, firma dalej nie wie, co jest naprawdę pilne.

Źródła pomocnicze: OWASP Web Security Testing Guide, OWASP Top 10, NCSC: CHECK penetration testing.