01
Przygotowanie
Potwierdzamy zakres, upoważnienie i warunki testu. Sprawdzamy dostęp do środowiska, kont i dokumentacji.
Pentesty aplikacji
Testy penetracyjne aplikacji
Sprawdzamy, czy można przejąć konto, uzyskać dostęp do cudzych danych lub obejść ważne reguły aplikacji. Testujemy aplikacje webowe i API w uzgodnionym zakresie. Wyniki opisujemy tak, aby Twój zespół mógł zaplanować poprawki.
Zaufali nam
Firmy i instytucje, dla których liczy się stabilne IT.
Bezpieczeństwo aplikacji w praktyce
Portal klienta, panel pracownika czy API partnera mogą udostępniać te same dane na różne sposoby. Test obejmuje uzgodnione funkcje i role użytkowników, nie tylko stronę logowania. Pomaga sprawdzić zabezpieczenia przed uruchomieniem, po zmianach lub podczas oceny dostawcy.
Co sprawdzamy w aplikacji
Scenariusze dobieramy do funkcji systemu, przetwarzanych danych i tego, jak korzystają z niego użytkownicy.
Konta i uprawnienia
Sprawdzamy, czy użytkownik może zobaczyć lub zmienić dane innej osoby, firmy albo roli. Weryfikujemy również dostęp do funkcji administracyjnych.Logowanie i sesje
Testujemy uzgodnione mechanizmy logowania, resetowania hasła, dodatkowego uwierzytelnienia oraz utrzymania i zakończenia sesji.API i przetwarzanie danych
Sprawdzamy kontrolę dostępu do API, obsługę danych wejściowych i plików, ujawnianie informacji oraz ograniczenia żądań.Procesy biznesowe
Weryfikujemy scenariusze właściwe dla aplikacji, np. płatności, zamówienia, limity i zatwierdzanie operacji. Szukamy możliwości obejścia uzgodnionych reguł.Ile informacji otrzymuje zespół testujący
Model uzgadniamy z Tobą. Większy dostęp do informacji zmienia zakres weryfikacji, ale sam nie gwarantuje wykrycia wszystkich błędów.
Bez kont i dokumentacji — black-box
Sprawdzamy aplikację z perspektywy osoby z zewnątrz, na podstawie informacji dostępnych w uzgodnionym zakresie.Z kontami i częścią dokumentacji — grey-box
Porównujemy dostępne funkcje i dane na kontach o różnych rolach. Możemy wykorzystać przekazaną dokumentację API.Z dostępem do kodu — white-box
Uzgodniony zakres może obejmować kod, architekturę i konfigurację. Przed pracami określamy, które elementy podlegają przeglądowi.Co otrzymuje Twój zespół
Raport dotyczy konkretnej wersji i zakresu aplikacji. Nie jest gwarancją braku podatności ani certyfikatem zgodności firmy.
Opis problemów do odtworzenia
Wskazane funkcje i role, warunki wystąpienia, żądania i odpowiedzi lub inne materiały potrzebne do odtworzenia potwierdzonego problemu.Ocena ryzyka i zalecenia
Ocena techniczna, wpływ na dane i procesy oraz rekomendowana kolejność działań. Zalecenia omawiamy z zespołem odpowiedzialnym za aplikację.Podsumowanie i dalsze kroki
Najważniejsze ustalenia dla kierownictwa, ograniczenia testu oraz lista obszarów do poprawy i ewentualnego ponownego sprawdzenia.Baseline — 10 lat cyklicznych pentestów
Od 10 lat cyklicznie wykonujemy pentesty platformy Baseline, wspierającej zarządzanie procesami biznesowymi i obieg dokumentów. Badamy moduły dostępne dla klientów oraz panel administracyjny, łącząc testy automatyczne ze szczegółową weryfikacją manualną. Po wdrożeniu poprawek przeprowadzamy retesty sprawdzające ich skuteczność. Nasze prace wspierają Baseline w utrzymaniu bezpieczeństwa platformy i pozytywnym przechodzeniu audytów prowadzonych przez TÜV NORD Polska.ISO 27001 · TÜV NORD Polska
System zarządzania bezpieczeństwem informacji Virtline jest certyfikowany przez TÜV NORD Polska. Zakres i ważność potwierdza opublikowany dokument.
Zobacz certyfikat VirtlineJak przebiega współpraca
Wyniki narzędzi łączymy z ręczną analizą funkcji, uprawnień i procesów aplikacji.
02
Testowanie
Wykonujemy uzgodnione scenariusze, analizujemy wyniki i w kontrolowany sposób weryfikujemy podatności. Istotne ograniczenia zapisujemy w raporcie.
03
Omówienie wyników
Przekazujemy raport i wyjaśniamy ustalenia zespołowi technicznemu oraz osobom decyzyjnym. Uzgadniamy priorytety poprawek.
04
Weryfikacja zmian
Jeśli została uzgodniona, po poprawkach ponownie sprawdzamy wskazane podatności. Dokumentujemy ich aktualny status i ograniczenia retestu.
Zakres praktyczny
Co ustalamy przed testem
Potrzebujemy zgody na testowanie oraz jasnych granic prac. Różne środowiska i role mogą wymagać osobnych scenariuszy.
Wskazujemy adresy, wersję systemu, objęte API i zależności od innych dostawców. Uzgadniamy, które działania można wykonać na produkcji.
Ustalamy role testowe oraz sposób przygotowania danych. Przekazanie kont i dokumentacji odbywa się uzgodnionym bezpiecznym kanałem.
Omawiamy procesy, których naruszenie najbardziej zaszkodzi firmie, np. dostęp do danych klientów lub zatwierdzanie płatności.
Określamy dozwolone techniki, limity, terminy oraz osoby do kontaktu i warunki przerwania prac.
Metodyka testów i źródła
OWASP ASVS porządkuje wymagania bezpieczeństwa aplikacji, a WSTG opisuje scenariusze testów. Zakres i wersje materiałów ustalamy dla konkretnej aplikacji i jej API, uwzględniając dane, role użytkowników i ryzyka uzgodnione z klientem. Źródła prawne poniżej uzupełniają ten kontekst; nie zastępują metodyki testowania ani nie oznaczają, że pentest potwierdza pełną zgodność firmy.
Źródło
OWASP WSTG
Przewodnik po scenariuszach testowania bezpieczeństwa aplikacji webowych.
Zobacz przewodnik OWASPŹródło
Rozporządzenie (UE) 2016/679 — RODO
Oficjalny tekst ogólnego rozporządzenia o ochronie danych w EUR-Lex.
Otwórz źródłoŹródło
ISO — ISO/IEC 27001:2022
Oficjalna karta normy określającej wymagania dla systemu zarządzania bezpieczeństwem informacji.
Otwórz źródłoPytania o testy penetracyjne
Czy test obejmuje API?
+
Tak, jeśli uwzględnimy je w zakresie. Ustalamy interfejsy, funkcje, role i dane do sprawdzenia. Dostępna dokumentacja API oraz konta testowe pomagają objąć scenariusze, których nie widać w samej przeglądarce.
Czy potrzebujecie kont testowych i kodu?
+
Nie zawsze. Możemy uzgodnić test bez kont, test z kontami o różnych rolach albo zakres obejmujący kod i dokumentację. Model zależy od celu. Przekazanie kodu nie oznacza automatycznie przeglądu całej aplikacji.
Czy można testować działającą aplikację?
+
Można uzgodnić test na produkcji, ale ryzyka nie da się całkowicie wyeliminować. Określamy dozwolone działania, godziny, ograniczenia i warunki przerwania. Scenariusze z większym ryzykiem wymagają osobnych ustaleń lub środowiska testowego.
Czy po poprawkach sprawdzicie aplikację ponownie?
+
Możemy wykonać retest wskazanych podatności. Jego zakres, termin i koszt ustalamy w ofercie lub osobno, przed pracami. Ponowna kontrola pojedynczych poprawek nie zastępuje pełnego testu nowej wersji aplikacji.
Porozmawiajmy o teście Twojej aplikacji
Opisz rodzaj aplikacji, najważniejsze funkcje, dostępne role i zakres API. Podaj, czy masz środowisko testowe oraz kiedy potrzebujesz wyników. Sposób bezpiecznego przekazania dostępów i poufnej dokumentacji ustalimy osobno.
Omów test aplikacji