Uwierzytelnianie
Obejście logowania, słabe hasła, niebezpieczne resetowanie hasła, czas życia sesji, konfiguracja MFA oraz logowania przez Profil Zaufany lub mObywatel, jeśli system z nich korzysta.
Skupiamy się na tym, co atakowane jest najczęściej: logowaniu, kontroli dostępu, obsłudze danych wejściowych i komponentach od zewnętrznych dostawców. Pracujemy według metodyki OWASP (WSTG i ASVS).
Obejście logowania, słabe hasła, niebezpieczne resetowanie hasła, czas życia sesji, konfiguracja MFA oraz logowania przez Profil Zaufany lub mObywatel, jeśli system z nich korzysta.
Czy klient zobaczy cudzą fakturę, zmieniając numer w adresie? Czy zwykły użytkownik dostanie się do panelu administratora? To jedne z najczęstszych błędów w portalach klienta.
SQL injection, cross-site scripting, przesyłanie złośliwych plików, manipulacja ceną lub ilością w żądaniu wysyłanym do serwera.
Endpointy, z których korzysta aplikacja na telefon, często są słabiej chronione niż strona www. Sprawdzamy autoryzację, limity zapytań i to, co aplikacja zapisuje w pamięci urządzenia.
Biblioteki ze znanymi podatnościami, włączony tryb debugowania, brak nagłówków bezpieczeństwa, dostępne kopie zapasowe i pliki .env, otwarte panele administracyjne.
Każde znalezisko z oceną według CVSS, sposobem odtworzenia i zaleceniem naprawy, plus streszczenie dla zarządu bez technicznego żargonu.
Czas testu zależy od wielkości aplikacji i zakresu, a termin raportu podajemy w umowie. Łączymy się z góry znanych adresów IP, które możesz dopisać do białej listy i monitoringu.
Pisemna zgoda właściciela systemu, dokładny zakres adresów i funkcji, okno czasowe testów i kontakty awaryjne po obu stronach. Jeśli aplikacja stoi u zewnętrznego hostingodawcy lub w chmurze, uzyskujemy też jego akceptację.
Mapujemy aplikację: punkty wejścia, technologie, publiczne API, subdomeny.
Ręcznie i narzędziami takimi jak Burp Suite, w trybie ostrożnym, bez działań, które mogłyby zakłócić pracę systemu.
Znaleziska z priorytetami, omówienie na spotkaniu online, a po poprawkach ponowne sprawdzenie naprawionych miejsc.
Raport z pentestu nie jest dokumentem do przesyłania mailem po całej firmie. Opisuje krok po kroku, jak wykorzystać każdą lukę, więc dopóki nie zostaną załatane, jest groźniejszy niż same podatności. Udostępniamy go szyfrowanym kanałem i tylko wskazanym osobom.
Działamy wyłącznie za pisemną zgodą właściciela systemu i na podstawie umowy z jasnym zakresem i terminem, a treść zgody warto uzgodnić z Twoim prawnikiem. Cudzych systemów nie testujemy nigdy, nawet na prośbę kogoś, kto twierdzi, że ma do nich prawo, bez dokumentu od faktycznego właściciela.
Pracujemy ostrożnie i bez testów niszczących, ale każde testowanie niesie pewne ryzyko. Dlatego wolimy kopię środowiska. Jeśli test ma objąć produkcję, wymagamy uzgodnionego okna czasowego i świeżej kopii zapasowej.
Skaner porównuje system z bazą znanych wzorców i dobrze znajduje przestarzałe biblioteki. Błędów logiki, takich jak dostęp do cudzych danych czy obejście limitu rabatu, skaner nie widzi. Tu potrzebny jest człowiek, a solidny test łączy jedno i drugie.
Nie wystawiamy certyfikatów bezpieczeństwa i nie obiecujemy ich. Dostajesz raport opisujący zakres, metodę, datę i wyniki testu oraz potwierdzenie retestu. Taki dokument możesz przedstawić audytorowi, klientowi lub w ramach analizy ryzyka pod NIS2.
Co najmniej raz w roku i po każdej większej zmianie, np. nowym module płatności albo przejściu na inną platformę. Dla podmiotów objętych NIS2 regularne testy są naturalną częścią zarządzania ryzykiem.
Opisz aplikację i napisz, czy masz środowisko testowe. Ustalimy zakres i okno testów, a zgodę spiszemy w umowie.
Zapytanie dotarło do nas
Odpowiedź dostaniesz w ciągu dnia roboczego, a jeśli zgłaszasz awarię, która zatrzymuje pracę, zajmiemy się nią w pierwszej kolejności.
Nie mamy tego miasta na liście. Sprawdź pisownię albo wybierz najbliższe duże miasto - pracujemy zdalnie, więc nie wpływa to na zakres obsługi.