Testy penetracyjne aplikacji webowych
Dla CTO, zespołów DevOps i compliance, którym nie wystarcza raport ze skanera. Ręcznie testujemy Twoją aplikację tak, jak zrobiłby to realny atakujący — łącząc błędy kontroli dostępu, wstrzyknięć i logiki biznesowej w wymierny wpływ — i przekazujemy uporządkowany, odtwarzalny raport, który inżynierowie mogą wdrożyć od razu.
Co testujemy
Wstrzyknięcia (SQL / NoSQL / OS command)
SQLi błędowe, ślepe boolean/time-based, second-order i stacked, a także wstrzyknięcia operatorów NoSQL i poleceń systemowych w każdym parametrze, nagłówku i polu JSON zależnym od użytkownika (WSTG-INPV-05/06, A03).
Cross-Site Scripting (reflected, stored, DOM)
XSS odbite i trwałe oraz kliencki DOM XSS (innerHTML, document.write, eval, location) osiągane przez przepływ danych source-to-sink, wraz z oceną obejścia CSP (WSTG-INPV-01/02).
Naruszona kontrola dostępu i IDOR
Eskalacja uprawnień pozioma i pionowa, niebezpieczne bezpośrednie odwołania do obiektów, forced browsing do niepowiązanych endpointów i brak autoryzacji na poziomie funkcji w akcjach zmieniających stan (WSTG-ATHZ, A01).
Uwierzytelnianie i zarządzanie sesją
Braki w blokadzie konta i odporności na credential stuffing, słabe procesy haseł/MFA, przewidywalne lub nierotowane tokeny sesji, session fixation i błędna obsługa JWT (alg=none, słaby sekret) — WSTG-ATHN/SESS, A07.
CSRF i SSRF
Brakujące lub podrabialne tokeny anty-CSRF i luki SameSite w żądaniach zmieniających stan oraz server-side request forgery sięgające usług wewnętrznych lub metadanych chmury (169.254.169.254) — WSTG-SESS-05, A10.
Nadużycia logiki biznesowej
Omijanie przepływów i maszyny stanów, manipulacja ceną/ilością, race condition na ograniczonych zasobach, nadużycia kuponów/zwrotów i wartości ujemne — których narzędzia automatyczne nie wykryją (WSTG-BUSL, A04).
Nieograniczony upload plików i path traversal
Obejście typu MIME i rozszerzenia do payloadów wykonywalnych, path traversal i local file inclusion oraz obsługa archiwów (zip-slip) — WSTG-BUSL-09, WSTG-ATHZ-01.
Niebezpieczna deserializacja i podatne komponenty
Deserializacja niezaufanych obiektów prowadząca do RCE oraz identyfikacja przestarzałych frameworków/bibliotek względem znanych CVE i ich osiągalnej powierzchni ataku (A08, A06).
Metodologia
- 1
Ustalenia i zakres (pre-engagement)
Na piśmie definiujemy cele, role, konta testowe, limity ruchu i zasady zaangażowania, uzgadniamy okno serwisowe dla testów inwazyjnych i potwierdzamy podpisaną autoryzację, zanim wyślemy jakikolwiek ruch (PTES pre-engagement).
- 2
Rekonesans i mapowanie
Pasywne i aktywne odkrywanie pełnej powierzchni aplikacji — tras, API, ukrytych parametrów, bundle’i JS i endpointów SPA — budując mapę pokrycia, z której wynika testowanie WSTG-INFO (PTES intelligence gathering).
- 3
Modelowanie zagrożeń
Priorytetyzujemy punkty wejścia, granice zaufania i zasoby o wysokiej wartości (auth, płatności, dane osobowe, admin), aby skupić wysiłek tam, gdzie naruszenie boli najbardziej (PTES threat modeling).
- 4
Testy ręczne i eksploatacja
Praktyczne testy we wszystkich kategoriach WSTG, a następnie bezpieczna eksploatacja proof-of-concept i kontrolowane łączenie podatności w realny, wykazywalny wpływ zamiast teoretycznych ustaleń (PTES exploitation).
- 5
Post-eksploatacja i analiza wpływu
Dla potwierdzonych błędów oceniamy zasięg — dostępne dane, uzyskane uprawnienia, ruch poprzeczny — i punktujemy każde ustalenie w CVSS v3.1 z opisem wpływu biznesowego (PTES post-exploitation).
- 6
Raportowanie i retest
Uporządkowany raport z krokami reprodukcji, dowodami i konkretną rekomendacją; techniczny debrief z zespołem oraz darmowy retest weryfikujący, że każda poprawka zamknęła problem (PTES reporting).
Standardy i odniesienia
Co otrzymujesz
- Podsumowanie zarządcze — Jednostronicowy, nietechniczny obraz poziomu ryzyka, kluczowych ustaleń i wpływu biznesowego dla zarządu i audytorów.
- Raport techniczny — Każda podatność z oceną CVSS, dotkniętymi endpointami, krok-po-kroku reprodukcją, dowodami request/response i odniesieniem do WSTG/CWE.
- Priorytetyzowany plan naprawczy — Poprawki uszeregowane wg ryzyka i nakładu, z konkretnymi wskazówkami kodu/konfiguracji do bezpośredniego wdrożenia przez developerów.
- List poświadczający (attestation) — Podpisane oświadczenie o wykonanych testach i zakresie — do wykorzystania wobec klientów, partnerów i w compliance (SOC 2, ISO 27001, PCI DSS).
- Darmowy retest i weryfikacja — Po naprawie ponownie testujemy potwierdzone ustalenia i wydajemy zaktualizowany raport pokazujący, co zostało zamknięte.
FAQ
Ile trwa test penetracyjny aplikacji webowej?+
Typowa aplikacja to 5–10 dni roboczych testów plus 2–3 dni na raport, zależnie od liczby ról, endpointów i procesów biznesowych. Po ustaleniu zakresu podajemy stałą liczbę osobodni i pewną datę dostawy — bez otwartych terminów.
Czego potrzebujecie, aby zacząć?+
Zdefiniowanego zakresu (URL/hosty), danych testowych dla każdej roli użytkownika, zgody na środowisko staging lub produkcję oraz podpisanej autoryzacji. Dla pełnego pokrycia preferujemy testy uwierzytelnione z co najmniej dwoma kontami na rolę, by rzetelnie ocenić kontrolę dostępu i IDOR.
Czy testy zepsują aplikację lub wpłyną na realnych użytkowników?+
Testujemy w miarę możliwości na środowisku staging i domyślnie używamy bezpiecznych, niedestrukcyjnych proof-of-conceptów. Testy inwazyjne (np. ryzykujące zmianę danych) uruchamiamy tylko w uzgodnionym oknie i w koordynacji z zespołem, a na żądanie możemy je spowolnić lub wstrzymać.
Czy to jest legalne i jak chronicie nasze dane?+
Testy prowadzimy wyłącznie na podstawie podpisanej autoryzacji i umowy o zasadach zaangażowania, co czyni je legalnymi. Wszystkie ustalenia i dane obejmuje NDA, dowody przechowujemy zaszyfrowane, a po zakończeniu prac usuwamy je na żądanie.
Czy to tylko uruchomienie automatycznych skanerów?+
Nie. Skanery znajdują rzeczy oczywiste, ale pomijają błędy kontroli dostępu, logiki biznesowej i łańcuchy podatności — te, które powodują realne włamania. Nasza praca jest przede wszystkim ręczna, zgodna z OWASP WSTG, a narzędzia przyspieszają pokrycie, nie zastępując testera.
Czy retest jest naprawdę darmowy?+
Tak. Jedna runda retestu ustaleń z pierwotnego raportu jest wliczona, dzięki czemu możesz udowodnić audytorom i klientom, że problemy faktycznie naprawiono, a nie tylko przyjęto do wiadomości.