Testy penetracyjne aplikacji webowych, które pokazują realną ścieżkę ataku.

Realizacja testu aplikacji webowej zajmuje od 5 dni roboczych. Na czas wpływają liczba modułów, ról, integracji i środowisk. Dokładny termin potwierdzamy w ofercie przed rozpoczęciem prac.

Nie. Skaner nie rozumie modelu biznesowego, relacji między użytkownikami i obiektami ani wpływu kilku połączonych błędów. Automatyzacja jest wsparciem, nie zamiennikiem testu manualnego.

Jedno podejście retestowe jest zazwyczaj w cenie, o ile oferta nie stanowi inaczej.

Tak, jeśli uzgodnione zasady ROE, okno prac i zabezpieczenia ryzyka na to pozwalają. Często rekomendujemy środowisko możliwie zbliżone do produkcji.

Tak. Testujemy IDOR, pomijanie kontroli dostępu, zmianę ról, dostęp poziomy i pionowy, wymuszone przeglądanie zasobów oraz operacje dostępne po wylogowaniu. Każdy przypadek weryfikujemy na poziomie rzeczywistego wpływu biznesowego.

Tak. Sprawdzamy nagłówki, CORS, tryby debug, komunikaty błędów, domyślne pliki, panele administracyjne, konfigurację serwera, cache i niepotrzebne funkcje. Ocenie podlega cały stos aplikacyjny, a nie tylko kod frontendu.

Tak. Analizujemy zależności, komponenty frontendowe i backendowe, artefakty buildów, rejestry pakietów, mechanizmy aktualizacji oraz zaufanie do skryptów zewnętrznych. Wskazujemy podatne biblioteki i słabe punkty procesu dostarczania oprogramowania.

Tak. Weryfikujemy TLS, szyfrowanie danych, zarządzanie kluczami, generowanie tokenów, hashowanie haseł, losowość, podpisy i błędne użycie algorytmów. Sprawdzamy także, czy dane wrażliwe są szyfrowane w odpowiednim miejscu i czasie.

Tak. Testujemy SQL, NoSQL, LDAP, XPath, OS command, template, expression language, header i code injection, a także XSS w wielu kontekstach. Automatyzacja służy do rekonesansu, a potwierdzenie i exploitację wykonuje pentester.

Tak. Analizujemy założenia zaufania, przepływy biznesowe, nadużycia funkcji, brak limitów i scenariusze, których nie wykryje skaner. W raporcie oddzielamy błąd implementacji od błędu architektury lub procesu.

Tak. Testujemy logowanie, MFA, reset hasła, odzyskiwanie konta, sesje, SSO, OAuth/OIDC, pamiętanie urządzeń i odporność na enumerację oraz credential stuffing. Sprawdzamy pełny cykl życia tożsamości i sesji.

Tak. Weryfikujemy integralność aktualizacji, serializację, podpisy webhooków, zaufanie do danych zewnętrznych i możliwość podmiany artefaktów lub konfiguracji. Testujemy również niebezpieczną deserializację i niezweryfikowane pakiety.

Tak. Sprawdzamy, czy krytyczne zdarzenia są rejestrowane, czy logi nie zawierają sekretów oraz czy atak może pozostać niewykryty. Raport wskazuje zdarzenia przydatne dla SOC/SIEM i propozycje scenariuszy detekcyjnych.

Tak. Wymuszamy błędy, przerwania transakcji, time-outy, niepełne dane, race conditions i niespójne stany. Szukamy fail-open, pominięcia autoryzacji, podwójnego wykonania operacji i wycieków przez obsługę wyjątków.

Tak. Analizujemy kolejność kroków, wartości ujemne, wielokrotne wykorzystanie benefitów, zmianę ceny, wyścigi, obejście akceptacji i operacje poza dozwolonym stanem procesu. Takie scenariusze są wykonywane ręcznie z kontrolą wpływu.

Tak. Sprawdzamy walidację typu i zawartości, parsery, ścieżki, publiczne buckety, przetwarzanie asynchroniczne, URL preview i dostęp do sieci wewnętrznej lub metadanych chmurowych. Test obejmuje również skutki przetwarzania złośliwego pliku.

Tak, jeżeli architektura i uzgodnione warunki pozwalają na bezpieczną walidację. Sprawdzamy różnice interpretacji żądań przez CDN, proxy, WAF i serwer aplikacyjny oraz możliwość wpływu na odpowiedzi innych użytkowników.

Tak. Sam frontend nie jest granicą bezpieczeństwa, dlatego analizujemy wywoływane API, tokeny, role, ukryte funkcje i backendowe kontrole dostępu. Zakres API potwierdzamy w ROE, aby nie pozostawić krytycznej części produktu poza testem.

Test aplikacji webowej zaczyna się od 2 000 PLN netto. Ostateczna cena zależy od liczby funkcji i ról, złożoności logiki biznesowej, integracji, jakości dokumentacji oraz wybranego modelu black-box, gray-box lub white-box. Zakres i wycenę przygotowujemy zwykle w około 24 godziny.

Warto sprawdzić doświadczenie w testach manualnych, przykładowy raport, sposób opisu wpływu biznesowego, zasady bezpiecznej walidacji oraz dostępność retestu. Sama lista używanych skanerów nie potwierdza jakości. Zespół BSTA ma ponad 1000 zrealizowanych pentestów, a większość ekspertów ponad 20 lat doświadczenia.

Najpierw ustalamy zakres, role, środowisko, wyłączenia i Rules of Engagement. Następnie wykonujemy rekonesans, testy uwierzytelniania, autoryzacji, danych wejściowych i logiki biznesowej, potwierdzamy wpływ bezpiecznym PoC, przygotowujemy raport i omawiamy wyniki. Po wdrożeniu poprawek zazwyczaj wykonujemy jeden retest.

Skaner wykrywa głównie znane wzorce techniczne i generuje wyniki wymagające weryfikacji. Pentest manualny sprawdza role, procesy, autoryzację, logikę biznesową oraz łączenie kilku słabości w realny scenariusz ataku. Raport pentestowy zawiera potwierdzone dowody, wpływ i konkretne zalecenia, a nie surową listę alertów.

Pentest może dostarczyć technicznego dowodu weryfikacji zabezpieczeń i planu naprawczego wspierającego te wymagania. Sam test nie zastępuje pełnego programu zgodności, zarządzania ryzykiem ani audytu regulacyjnego. W raporcie możemy wskazać mapowanie wyników do właściwych kontroli i wymagań klienta.

Black-box dobrze odwzorowuje perspektywę zewnętrznego napastnika, gray-box zwiększa pokrycie dzięki kontom dla różnych ról, a white-box pozwala przeanalizować także kod i architekturę. Dla aplikacji biznesowych najczęściej rekomendujemy gray-box z kilkoma rolami, ponieważ pozwala dokładnie sprawdzić autoryzację i separację danych.

Najlepiej testować przed istotnym wdrożeniem, po dużych zmianach oraz okresowo w środowisku możliwie zbliżonym do produkcyjnego. Po uruchomieniu warto zweryfikować konfigurację brzegową, domeny, CDN, WAF i integracje, których nie było na testowym środowisku. Krytyczne systemy powinny mieć zaplanowany cykl testów, nie jednorazowy audyt.

Nie. WAF i CDN mogą ograniczyć część ataków wejściowych, ale nie naprawiają błędów autoryzacji, logiki biznesowej, separacji tenantów ani wad procesu. Podczas testu sprawdzamy aplikację w rzeczywistej architekturze i oceniamy zarówno działanie warstwy ochronnej, jak i możliwość jej ominięcia.

Raport powinien zawierać podsumowanie dla zarządu, zakres i ograniczenia, metodykę, potwierdzone podatności, CVSS, wpływ biznesowy, bezpieczne dowody PoC, kroki reprodukcji, rekomendacje oraz kryteria zamknięcia. Ważne są także priorytety napraw i wynik retestu. Przykładowy 30-stronicowy raport BSTA jest dostępny na stronie.

Tak. W e-commerce sprawdzamy między innymi ceny, płatności, kupony, zwroty i dostęp do zamówień, a w SaaS separację tenantów, role, eksporty, zaproszenia i procesy administracyjne. Zakres jest budowany wokół wartościowych procesów biznesowych, a nie samej liczby adresów URL.

W zapytaniu warto podać krótki opis systemu, środowisko, liczbę ról i modułów, technologie, API i integracje, oczekiwany termin, wymagania raportowe oraz potrzebę retestu. Nie trzeba przesyłać sekretów ani danych dostępowych na etapie wyceny. Jeśli zakres nie jest jeszcze znany, BSTA pomaga go ustalić podczas krótkiej konsultacji.