Skaner podatności znajdzie nieaktualną bibliotekę i źle ustawiony nagłówek, ale nie zauważy, że zalogowany klient może podejrzeć cudze zamówienie, zmieniając numer w adresie. Takie błędy uprawnień i logiki biznesowej są jedną z najczęstszych przyczyn wycieków danych z aplikacji webowych i właśnie do ich znajdowania służy test penetracyjny. Poniżej wyjaśniamy, czym pentest różni się od innych metod, jak go przygotować, co powinien zawierać raport i ile kosztuje.
Krótka odpowiedź
Pentest aplikacji webowej trwa zwykle od 1 do 3 tygodni i kosztuje od około 8 000 zł netto za prostą aplikację do 60 000 zł i więcej za platformę z płatnościami, API i aplikacją mobilną. Najwięcej wartości daje test metodą szarej skrzynki: tester dostaje konta w każdej roli i dokumentację API, więc w ograniczonym czasie sprawdza uprawnienia, logikę i dane, zamiast zgadywać, jak działa system. Wynikiem jest raport z listą podatności ocenionych w skali CVSS, dowodami i zaleceniami, a po poprawkach retest, który potwierdza ich skuteczność. Pentest robi się przed uruchomieniem aplikacji z danymi osobowymi lub płatnościami, po dużych zmianach i cyklicznie, zwykle raz w roku.
Pentest, skan i przegląd kodu to różne narzędzia
| Metoda | Co sprawdza | Czego nie wykryje | Kiedy stosować |
|---|---|---|---|
| Skan automatyczny | znane podatności, wersje komponentów, nagłówki, konfigurację TLS | błędów uprawnień i logiki biznesowej | stale, na przykład co miesiąc |
| Test penetracyjny | ręczne próby ataku według metodyki, łączenie drobnych słabości w realny scenariusz | wszystkiego poza zakresem i czasem testu | przed startem, po dużych zmianach, raz w roku |
| Przegląd kodu | błędy w kodzie, sekrety w repozytorium, niebezpieczne funkcje | konfiguracji serwera i środowiska produkcyjnego | przy modułach krytycznych: płatnościach, uprawnieniach |
| Audyt infrastruktury | serwery, chmurę, kopie zapasowe, dostęp administracyjny | podatności samej aplikacji | przy zmianie hostingu i cyklicznie |
Te metody się uzupełniają. Skaner taniej wyłapuje oczywiste braki, więc pentest nie powinien być pierwszą kontrolą aplikacji, w której nikt nie zaktualizował bibliotek od roku. Szerzej o zagrożeniach i podstawach ochrony piszemy w artykule o bezpieczeństwie aplikacji webowej.
Czarna, szara czy biała skrzynka
| Podejście | Co dostaje tester | Zalety | Ograniczenia |
|---|---|---|---|
| Czarna skrzynka (black box) | tylko adres aplikacji | realistycznie pokazuje, co zobaczy anonimowy atakujący | dużo czasu idzie na rozpoznanie, mniej znalezisk za tę samą cenę |
| Szara skrzynka (grey box) | konta w każdej roli, dokumentację API, opis procesów | najlepszy stosunek wyników do ceny, sprawdza uprawnienia między rolami | wymaga przygotowania kont i danych testowych |
| Biała skrzynka (white box) | dodatkowo kod źródłowy i architekturę | najgłębsza analiza, łączy pentest z przeglądem kodu | najdroższa, ma sens przy systemach krytycznych |
Dla większości aplikacji firmowych rekomendujemy szarą skrzynkę. Atakujący i tak może założyć konto klienta, a najgroźniejsze błędy dotyczą tego, co zalogowany użytkownik może zrobić z cudzymi danymi.
Co sprawdza dobry pentest aplikacji
Punktem odniesienia są dokumenty organizacji OWASP: lista OWASP Top 10 z najczęstszymi kategoriami podatności, przewodnik Web Security Testing Guide z opisem testów oraz standard ASVS, który dzieli wymagania na trzy poziomy. Poziom pierwszy wystarcza dla prostych serwisów, drugi jest właściwy dla aplikacji z danymi osobowymi i płatnościami, a trzeci dla systemów krytycznych. Dla interfejsów API stosuje się osobną listę OWASP API Security Top 10.
W praktyce tester sprawdza uwierzytelnianie i sesje (limity prób logowania, reset hasła, logowanie dwuskładnikowe, wylogowanie), kontrolę dostępu (czy klient zobaczy cudze dane, czy pracownik wykona akcję administratora), wstrzyknięcia do bazy danych i poleceń systemowych, ataki XSS i CSRF, żądania wysyłane przez serwer do innych adresów (SSRF), przesyłanie plików, API (zbyt szerokie odpowiedzi, przypisywanie pól, których użytkownik nie powinien zmieniać) i konfigurację. Najwięcej wartości daje logika biznesowa: czy da się nałożyć rabat dwa razy, zmienić cenę w koszyku, zapłacić za tańszy wariant i odebrać droższy albo zmienić status zamówienia z pominięciem płatności. Tego nie znajdzie żaden skaner.
Jak przygotować aplikację do testu
Zakres trzeba ustalić na piśmie: adresy, środowisko, role, funkcje objęte testem i wyłączenia. Właściciel systemu musi wydać pisemne upoważnienie, bo próby przełamania zabezpieczeń bez zgody mogą naruszać przepisy Kodeksu karnego o nielegalnym dostępie do systemu. Najlepiej testować na środowisku testowym, które odpowiada produkcji, z danymi testowymi zamiast prawdziwych danych osobowych. Tester potrzebuje kont w każdej roli, dokumentacji API, osoby kontaktowej na wypadek awarii oraz informacji, kiedy może pracować. Jeśli aplikacja stoi za zaporą sieciową albo u zewnętrznego dostawcy hostingu, warto uprzedzić dostawcę lub dodać adresy testera do wyjątków, żeby zapora nie blokowała testu po kilku minutach. Przed testem trzeba też zrobić kopię zapasową danych.
Co powinien zawierać raport
Dobry raport ma dwie części. Pierwsza jest dla zarządu: kilka akapitów o poziomie ryzyka, najważniejszych problemach i rekomendacjach, bez żargonu. Druga jest dla zespołu technicznego: każda podatność z opisem, oceną w skali CVSS, krokami odtworzenia, dowodem (żądaniem, odpowiedzią, zrzutem ekranu), wpływem na biznes i zaleceniem naprawy. Raport powinien też jasno mówić, czego nie testowano, bo brak znalezisk w niesprawdzonym module niczego nie dowodzi.
| Ocena | Zakres CVSS | Przykład | Zalecany termin naprawy |
|---|---|---|---|
| Krytyczna | 9,0 - 10,0 | przejęcie konta administratora, dostęp do całej bazy danych | natychmiast |
| Wysoka | 7,0 - 8,9 | podgląd cudzych zamówień po zmianie numeru w adresie | do 7 dni |
| Średnia | 4,0 - 6,9 | brak limitu prób logowania, zbyt długa ważność sesji | do 30 dni |
| Niska | 0,1 - 3,9 | ujawnienie wersji serwera w nagłówkach | przy najbliższej aktualizacji |
Po wdrożeniu poprawek robi się retest, czyli ponowne sprawdzenie wszystkich zgłoszonych podatności. Dopiero raport z retestu potwierdza, że problemy zostały usunięte, i to on jest dokumentem, który pokazuje się klientom, audytorom albo ubezpieczycielowi.
Kiedy robić pentest i jak często
Pierwszy test robi się przed uruchomieniem aplikacji, która przetwarza dane osobowe, dane o zdrowiu lub płatności. Kolejne po dużych zmianach: nowych rolach, module płatności, otwarciu API dla partnerów, zmianie sposobu logowania. Do tego test cykliczny, zwykle raz w roku, i test po każdym incydencie bezpieczeństwa. Coraz częściej pentestu wymagają też klienci korporacyjni w umowach, zamawiający w przetargach i ubezpieczyciele polis cybernetycznych, a podmioty publiczne mają obowiązek okresowego audytu bezpieczeństwa informacji wynikający z Krajowych Ram Interoperacyjności.
Ważna jest niezależność. Zespół, który zbudował aplikację, zna jej założenia i nieświadomie testuje to, co sam zaprojektował. Dlatego pentest najlepiej zlecić zespołowi, który aplikacji nie tworzył, a wyniki omówić z jej twórcami.
Ile kosztuje pentest aplikacji webowej
| Zakres | Przykład | Czas pracy testera | Koszt netto |
|---|---|---|---|
| Prosta aplikacja | do dwóch ról, kilkanaście ekranów, bez płatności | około 40 godzin | 8 000 - 15 000 zł |
| Aplikacja średnia | kilka ról, panel administracyjny, API, integracje | 60-120 godzin | 15 000 - 30 000 zł |
| Platforma | płatności, aplikacja mobilna, wiele integracji, wielu klientów w jednym systemie | od 120 godzin | 30 000 - 60 000 zł i więcej |
| Retest | ponowne sprawdzenie zgłoszonych podatności | kilka do kilkunastu godzin | często w cenie, inaczej 10-20 procent ceny testu |
Cenę podnosi liczba ról i ścieżek w aplikacji, API do przetestowania, aplikacja mobilna, testy na produkcji poza godzinami pracy i wymagany format raportu, na przykład w dwóch językach. Obniża ją dobre przygotowanie: gotowe konta testowe, dokumentacja API i stabilne środowisko testowe.
Jak ByteWave prowadzi testy bezpieczeństwa
Testujemy metodą szarej skrzynki według przewodnika OWASP, łącząc testy ręczne z automatycznymi skanami, a raport przygotowujemy po polsku, z częścią dla zarządu i częścią techniczną. Retest zgłoszonych podatności jest w cenie. Jako software house możemy też poprawić znalezione błędy albo wesprzeć zespół, który rozwija aplikację. Dla Gminy Syców przeprowadziliśmy testy penetracyjne infrastruktury i przygotowaliśmy dokumentację systemu zarządzania bezpieczeństwem informacji dla dwóch jednostek. Serwis i BIP Centralnej Stacji Ratownictwa Górniczego przed odbiorem przeszedł osobny audyt bezpieczeństwa, który potwierdził zastosowane zabezpieczenia. O tym, jak bezpieczeństwo wpisać w opiekę nad systemem po wdrożeniu, piszemy w tekście o utrzymaniu aplikacji.
Najczęściej zadawane pytania
Czy pentest można zrobić na produkcji
Można, ale ostrożniej: w uzgodnionym oknie czasowym, bez testów, które mogą zniszczyć dane lub przeciążyć serwer, i z aktualną kopią zapasową. Bezpieczniej testować na środowisku testowym, które odpowiada produkcji.
Czym pentest różni się od audytu bezpieczeństwa
Audyt jest szerszy i obejmuje procesy, dokumentację, konfigurację i zgodność z wymaganiami. Pentest to praktyczna symulacja ataku na konkretną aplikację. Często łączy się oba w jednym zleceniu.
Jak często robić testy penetracyjne
Raz w roku i po każdej dużej zmianie w aplikacji. Systemy krytyczne testuje się częściej, a między testami warto prowadzić stałe skanowanie automatyczne.
Czy pentest może uszkodzić aplikację
Rzadko, jeśli zakres jest dobrze ustalony. Testy niszczące wyklucza się z zakresu, a tester natychmiast informuje o krytycznym znalezisku, zamiast czekać na raport.
Chcesz sprawdzić, czy aplikacja wytrzyma atak? ByteWave przeprowadzi test penetracyjny metodą szarej skrzynki, przygotuje raport z oceną ryzyka i zaleceniami oraz sprawdzi poprawki w reteście. Skontaktuj się z nami.