Testy penetracyjne aplikacji webowych
Aplikacja webowa jest wystawiona do Internetu przez całą dobę i najczęściej stanowi pierwszy cel ataku. Sprawdzamy ją tak, jak zrobiłby to atakujący z ograniczonym czasem i konkretnym celem: dostać się do danych, uzyskać kontrolę nad infrastrukturą albo dostęp do konta o wyższych uprawnieniach.
Pracujemy zgodnie z OWASP Top 10, OWASP ASVS i Web Security Testing Guide. Podstawą są testy manualne, bo skaner nie znajdzie błędu w logice biznesowej ani sposobu na wejście na cudze konto.
Doświadczenie: ponad 500 testów penetracyjnych rocznie, m.in. dla banków, domów maklerskich, firm leasingowych, energetycznych, telekomunikacyjnych, produkcyjnych i e-commerce.
Dowiedz się więcejZakres naszych testów jest zgodny z aktualną edycją. W praktyce oznacza to więcej uwagi poświęconej kontroli dostępu, konfiguracji i komponentom zewnętrznym, a mniej powtarzania scenariuszy, które nowoczesne frameworki obsługują domyślnie.
Co obejmują pentesty aplikacji webowych
Zakres pentestów aplikacji webowych ustalamy przed startem, ale w typowy projekt obejmuje:
Kontrola dostępu i autoryzacja
Najczęstsze źródło poważnych podatności. Sprawdzamy dostęp do danych innych użytkowników przez podmianę identyfikatora, dostęp do funkcji zarezerwowanych dla wyższych ról, obejście kontroli po stronie interfejsu oraz żądania kierowane przez aplikację do zasobów wewnętrznych (SSRF).
Logika biznesowa
Niezwykle istotne kwestie, niestety często pomijane przy testach: manipulacja procesem zakupowym, cenami, rabatami i limitami, wykonywanie kroków poza przewidzianą kolejnością, powtarzanie operacji, które powinny wykonać się raz, obchodzenie warunków akceptacji. Tych błędów nie znajdzie żaden skaner, bo z technicznego punktu widzenia aplikacja działa poprawnie.
Uwierzytelnianie i sesja
Obejście logowania, obsługa biometrii, żywotność i unieważnianie tokenów, zachowanie aplikacji po zmianie hasła, brak ograniczeń liczby prób logowania, poprawność wylogowania na wszystkich urządzeniach.
Komponenty i łańcuch dostaw
Biblioteki i frameworki ze znanymi podatnościami, komponenty z nieaktualnymi zależnościami, skrypty ładowane z zewnętrznych źródeł, integracje z usługami trzecich stron.
Obsługa plików i błędów
Wgrywanie plików i możliwość uruchomienia treści po stronie serwera, dostęp do plików spoza katalogu aplikacji, zachowanie aplikacji przy nieoczekiwanych danych i przeciążeniu, ujawnianie informacji w śladach stosu.
API wykorzystywane przez aplikację
Nowoczesna aplikacja webowa to głównie interfejs do API. Testujemy autoryzację na poziomie obiektów i funkcji, nadmiarowe dane w odpowiedziach, brak limitów zapytań i niespójności między walidacją w interfejsie a walidacją po stronie serwera. Każdą potwierdzoną podatność wyceniamy według CVSS lub OWASP Risk Rating Methodology.
Konfiguracja i ekspozycja
Nagłówki bezpieczeństwa, konfiguracja TLS, dostępne panele administracyjne, katalogi i pliki pozostawione na serwerze, komunikaty błędów ujawniające szczegóły środowiska, domyślne poświadczenia, konfiguracja CORS.
Wstrzyknięcia i przetwarzanie danych wejściowych
SQL injection, wstrzyknięcia poleceń i szablonów, XSS w wariantach odbitym, trwałym i opartym na DOM, deserializacja niezaufanych danych, przetwarzanie XML.
Każdą potwierdzoną podatność wyceniamy według CVSS lub OWASP Risk Rating Methodology.
Skontaktuj się z nami
Warianty testów penetracyjnych aplikacji WWW
Black-box – bez wiedzy o systemie, wyłącznie z pozycji użytkownika zewnętrznego. Najbliżej realnego scenariusza, ale przy ograniczonym czasie część funkcji może pozostać nieprzetestowana, a część podatności niewykryta.
Grey-box – najczęstszy wybór. Konta testowe dla każdej roli, dokumentacja i informacje o architekturze pozwalają dotrzeć do logiki biznesowej zamiast tracić czas na mapowanie aplikacji.
White-box – z dostępem do kodu źródłowego i konfiguracji. Najdokładniejsze, wychwytuje błędy niewidoczne lub trudne di wykrycia z zewnątrz.
Niezależnie od wariantu testujemy aplikacje dostępne z Internetu oraz te działające wyłącznie wewnątrz sieci. Pracujemy zdalnie lub w siedzibie Klienta, jeśli wymaga tego polityka bezpieczeństwa.
Jeżeli zależy Ci na pełnej analizie kodu, sprawdź audyt kodu źródłowego. Przy aplikacji mocno opartej na integracjach warto rozszerzyć zakres o testy bezpieczeństwa API, a przy wersji mobilnej tego samego produktu o pentest aplikacji mobilnych.
Dlaczego skan podatności nie zastępuje testu penetracyjnego?
Skaner sprawdza wzorce. Wykryje brakujący nagłówek, przestarzałą bibliotekę i typowe miejsce na wstrzyknięcie – jeśli w ogóle dotrze do lokalizacji – w których znajduje się błąd. Jest szybki, tani i dobrze sprawdza się w cyklicznym monitorowaniu, jednak po odpowiedniej konfiguracji dla danej aplikacji.
Nie odpowie natomiast na pytania, które decydują o realnym ryzyku: czy użytkownik z rolą podstawową dotrze do danych innego klienta, czy da się zamówić towar z ceną ustawioną po stronie przeglądarki, czy proces zwrotu można wykonać dwa razy na tej samej transakcji. To wymaga zrozumienia, co aplikacja ma robić zależnie od kontekstu biznesowego i typu aplikacji, a tego skaner nie wie.
Nasza metodyka opiera się na testach manualnych. Narzędzia automatyczne stosujemy pomocniczo, żeby szybko odsiać oczywiste błędy i skupić czas pentestera tam, gdzie ma to znaczenie. Realizujemy też same skany automatyczne, jako cykliczne przeglądy między pełnymi testami, do wychwytywania najprostszych podatności.
Korzyści
Co dostajesz po testach penetracyjnych aplikacji webowych?
Podatności potwierdzone, nie zgłoszone przez narzędzie
Każde znalezisko ma proof of concept: kroki odtworzenia, zrzuty ekranu, zmodyfikowane żądania, fragmenty logów. Zespół deweloperski nie traci czasu na sprawdzanie, czy błąd istnieje.
Potwierdzenie po poprawkach
Re-testy weryfikują, czy podatność faktycznie zniknęła i czy przy okazji nie powstała nowa.
Kolejność napraw według ryzyka
Rekomendacje uszeregowane od tych, które mogą realnie kosztować pieniądze, po informacyjne. Wiesz, co musi zdążyć przed najbliższym wydaniem.
Wnioski dla procesu wytwarzania
Jeżeli te same klasy błędów wracają w kolejnych wersjach, problem leży w procesie. Wdrażamy Secure SDLC i włączamy automatyczne testy bezpieczeństwa do pipeline'u CI/CD.
Dokument do przedstawienia na zewnątrz
Niezależna ocena według uznanych standardów, którą pokażesz klientowi korporacyjnemu, audytorowi lub ubezpieczycielowi.
Materiał dla Zarządu
Streszczenie bez terminologii technicznej, z opisem możliwych skutków finansowych, reputacyjnych i prawnych.
Kiedy przeprowadzić pentesty aplikacji webowych
- Przed wdrożeniem produkcyjnym nowej aplikacji lub większego modułu.
- Po zmianach w kontroli dostępu, procesie logowania albo modelu ról.
- Po integracji z nowym dostawcą płatności, systemem zewnętrznym lub API partnera.
- Przed audytem, certyfikacją albo przeglądem bezpieczeństwa u klienta korporacyjnego.
- Po incydencie, żeby sprawdzić, czy ta sama klasa błędu nie występuje w innych miejscach systemu.
- Cyklicznie, co 3 do 24 miesięcy, zależnie od wrażliwości danych, poziomu ryzyka i liczby zmian w aplikacji.
Aplikacja webowa a wymogi NIS2, UoKSC i DORA
Nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa, wdrażająca dyrektywę NIS2, weszła w życie 3 kwietnia 2026 r. Podmioty kluczowe i ważne mają czas na dostosowanie do 3 kwietnia 2027 r., a podmioty kluczowe muszą przeprowadzić pierwszy audyt bezpieczeństwa do 3 kwietnia 2028 r. i powtarzać go nie rzadziej niż co trzy lata. Instytucje finansowe realizują równolegle obowiązki wynikające z rozporządzenia DORA.
Przepisy wymagają wykazania, że zabezpieczenia zostały sprawdzone w praktyce, a ryzyko oszacowane i udokumentowane. Raport z testów penetracyjnych aplikacji webowej dostarcza dowodu dla systemu, przez który obsługujesz klientów i przetwarzasz najwięcej danych. Jeżeli chcesz połączyć testy z warstwą formalną, zobacz audyt zgodności z NIS2 i UoKSC.
Dlaczego warto powierzyć nam pentesty aplikacji www?
Skala. Ponad 500 testów penetracyjnych rocznie. Duża część naszych znalezisk powtarza się między klientami, więc wiemy, gdzie szukać najpierw.
Zespół. Ponad 20 inżynierów bezpieczeństwa z certyfikatami OSCP, OSCE, OSWE, OSEE, CEH, CISSP, CISA, eWPT i eWPTX, z doświadczeniem w administracji systemami i programowaniu.
Jakość i niezależny przegląd. Dostajesz raport, a nie wynika pracy narzędzi. Raport jest wynikiem pracy przynajmniej dwóch niezależnych pentesterów lub zespołów – jeden wykonuje prace, drugi niezależnie weryfikuje ich wyniki i raport.
Metodyka na uznanych standardach. OWASP Top 10, OWASP ASVS, OWASP Web Security Testing Guide, PCI DSS, PTES, ISSAF, PTF, NIST SP 800-115, metodyka LPT EC-Council, P-PEN WAT. Ryzyko szacujemy według CVSS, OWASP RRM i WASC Threat Classification.
Dwie osoby kontaktowe. Pentester Wiodący odpowiada na pytania techniczne w trakcie testów, Project Manager pilnuje terminów i ustaleń.
Ochrona materiałów z testów. Zgodnie z ISO 27001: szyfrowanie dysków, szyfrowanie plików i załączników PGP, kontrola i monitorowanie dostępu do danych oraz raportów.
Wyjście poza jednorazowy test. Opracowujemy, optymalizujemy i wdrażamy Secure SDLC oraz włączamy automatyczne testy bezpieczeństwa do pipeline’u CI/CD.
Skontaktuj się z nami
Raport z testów penetracyjnych aplikacji webowej
Raport pisany jest dla dwóch odbiorców i tak też jest podzielony.
Część dla Zarządu i osób decyzyjnych:
- cel i zakres wykonanych prac,
- zastosowane podejście,
- podsumowanie wyników językiem biznesowym, bez terminologii technicznej,
- ogólna ocena poziomu bezpieczeństwa aplikacji.
Część techniczna, dla każdej podatności:
- tytuł i szczegółowy opis,
- proof of concept: sposób wywołania podatności wraz z dowodami (zrzuty ekranu, zmanipulowane zapytania, listingi poleceń, fragmenty logów),
- opis możliwych skutków wykorzystania,
- poziom ryzyka według CVSS lub OWASP RRM w skali: krytyczny, wysoki, średni, niski, informacyjny,
- odniesienie do publicznych baz podatności,
- rekomendacja naprawcza z opisem sposobu wdrożenia, dopasowana do specyfiki Twojej aplikacji.
Raport zawiera też zakres i datę testów, listę zastosowanych metodyk i technik oraz wykorzystane narzędzia.
Najczęściej zadawane pytania
Wycena zależy od liczby modułów i ról użytkowników, złożoności logiki biznesowej, wariantu testów oraz tego, czy zakres obejmuje API i infrastrukturę. Podajemy ją po wstępnej rozmowie, zawsze jako konkretną pracochłonność, a nie gotowy pakiet.
Od 1 do 4 tygodni, zależnie od złożoności aplikacji. Termin i pracochłonność ustalamy przed startem.
Adresu aplikacji, kont testowych dla każdej roli oraz zgody na testy. Przy wariancie grey-box lub white-box dodatkowo dokumentacji, opisu architektury i dostępu do kodu.
Preferujemy środowisko testowe odwzorowujące produkcję. Jeżeli test musi objąć produkcję, ustalamy okno czasowe i zakres dopuszczalnych operacji, a w trakcie prac utrzymujemy stały kontakt z Twoim zespołem.
Zależnie od uzgodnionego zakresu. Rekomendujemy objęcie API testami, bo w aplikacjach opartych na frontendzie po stronie przeglądarki większość poważnych podatności ujawnia się właśnie tam. Rekomendujemy też pokrycie testami infrastruktury, bo nawet najlepsza aplikacja może być skompromitowana, jeśli infrastruktura nie będzie bezpieczna.
Skaner wskazuje, że coś wygląda podejrzanie, i robi to w godziny, nie docierając zwykle do wszystkich funkcji aplikacji. Test penetracyjny potwierdza, że da się to wykorzystać, pokazuje skutek i trwa tygodnie. Skan jest dobry jako cykliczny przegląd między pełnymi testami, nie jako ich zamiennik.
Tak. Zakres uwzględnia aktualną edycję, w tym nowe kategorie dotyczące łańcucha dostaw oprogramowania oraz obsługi sytuacji wyjątkowych (w zależności od ustalonego zakresu).
Burp Suite Pro jako podstawowe środowisko pracy, dalej m.in. sqlmap, ffuf, nuclei, OWASP ZAP, Nikto, DirBuster, testssl oraz skanery Acunetix i Invicti. Do testów haseł john the ripper, hashcat i THC Hydra. Uzupełniamy je autorskimi narzędziami pisanymi pod konkretne przypadki.
Tak. Wspieramy zespół przy naprawie, prowadzimy szkolenia z usuwania podatności i wykonujemy re-testy potwierdzające skuteczność poprawek.
Tak. Wdrażamy automatyczne testy bezpieczeństwa w pipeline CI/CD oraz opracowujemy i optymalizujemy Secure SDLC.
Zwykle co 3 do 24 miesięcy, zależnie od wrażliwości danych, poziomu ryzyka i tempa zmian. Przy szybkim cyklu wydawniczym sprawdza się model: pełny test raz w roku plus węższe testy po większych wydaniach. Pomagamy zbudować plan ciągłego monitorowania bezpieczeństwa.
Tak, przy współpracy długoterminowej warunki są korzystniejsze niż przy pojedynczym projekcie.
Zgodnie z ISO 27001: kontrola dostępu do serwerowni i zasobów sieciowych, szyfrowanie dysków, szyfrowanie plików i załączników PGP, szyfrowanie treści wiadomości, ciągłe monitorowanie dostępu.