Tożsamość i uprawnienia
Logowanie i odzyskiwanie konta, cykl życia sesji oraz dostęp do danych i funkcji z różnych ról.
Bezpieczeństwo aplikacji webowych
Sprawdź, czy role i procesy w aplikacji można wykorzystać do ataku.
Ręcznie analizujemy logowanie, sesje, uprawnienia i operacje wieloetapowe. Łączymy błędy techniczne z logiką biznesową, aby pokazać ich wpływ i wskazać priorytety naprawy.
Napisz, jaki system chcesz sprawdzić, z jakiego powodu i w jakim terminie. Odpowiemy, jakie informacje pomogą przygotować propozycję. Dokumentację i dane dostępowe przekażesz później uzgodnionym, bezpiecznym kanałem.
Od 2007 roku rozwijamy doświadczenie w bezpieczeństwie IT.
Ręczna analiza wspierana narzędziami i oceną ryzyka.
Uzgodnione re-testy pomagają sprawdzić wdrożone poprawki.
Co sprawdzamy
Najważniejsze błędy często pojawiają się między funkcjami.
Poniższe obszary dobieramy do funkcji, ról i architektury aplikacji. Konkretne granice badania ustalamy przed rozpoczęciem.
Przepływy i logika biznesowa
Sprawdzamy, czy można pominąć etap procesu, zmienić kolejność operacji lub wykorzystać założenia biznesowe wbrew ich przeznaczeniu.
Przetwarzanie danych
Dane wejściowe i wyjściowe, przesyłanie plików oraz komunikaty błędów, które mogą ujawniać informacje lub zmieniać działanie aplikacji.
Interfejsy i integracje
Badamy, jak interfejs korzysta z API i usług zewnętrznych. Osobny test backendu wymaga ustalenia jego granic.
Kiedy zaplanować test
Przed wdrożeniem lub po zmianie ważnego procesu.
Test pomaga ocenić ryzyko przed uruchomieniem aplikacji, po zmianach w logowaniu lub uprawnieniach, przy wymaganiach klienta i w ramach okresowej kontroli. Harmonogram ustalimy po poznaniu systemu.
Co pomoże ustalić wycenę?
- Funkcje i roleNajważniejsze procesy, typy kont i operacje wymagające szczególnej ochrony.
- ŚrodowiskoAdres wersji do testów, zależności od API i oczekiwany termin.
- Konta i materiałyPotrzebne role i scenariusze wskażemy podczas przygotowania. Dane dostępowe i dokumentację przekażesz później uzgodnionym, bezpiecznym kanałem.
Co otrzymujesz po teście
Raport, który pomaga zaplanować i wdrożyć poprawki.
Każde ustalenie opisujemy w kontekście badanego systemu: jak powstaje problem, co może umożliwić i jak go usunąć. Ocena ryzyka i priorytety pomagają zespołowi ułożyć prace naprawcze.
Zanonimizowany przykładowy raport załączamy do ofert przygotowywanych po ustaleniu zakresu testu.
- Potwierdzone ustaleniaOpis podatności, warunków jej wystąpienia i kroków pozwalających odtworzyć problem.
- Wpływ i możliwa ścieżka atakuWyjaśnienie, do czego błąd może prowadzić w badanym systemie.
- Ocena ryzyka i priorytetyPodstawa do ustalenia kolejności prac.
- Rekomendacje dla zespołu technicznegoWskazówki, które można przełożyć na zadania naprawcze.
- Podsumowanie dla osób decyzyjnychZwięzły obraz ustaleń i ich znaczenia dla organizacji.
- Uzgodnione re-testySprawdzenie wdrożonych poprawek na zasadach ustalonych z klientem.
Jak pracujemy
Od pierwszej rozmowy do sprawdzenia uzgodnionych poprawek.
W każdym etapie wiadomo, co przygotować, co badamy i jak wykorzystać wyniki.
Poznajemy system
Pytamy o system, powód testu, oczekiwany termin i decyzje, które mają wesprzeć wyniki.
Planujemy badanie
Określamy granice testu, środowisko, role, dostęp i dopuszczalne scenariusze.
Przygotowujemy dostęp
Wybieramy kanał komunikacji i bezpieczny sposób przekazania dokumentacji oraz danych dostępowych.
Testy
Ręcznie analizujemy system, korzystamy z narzędzi pomocniczych i sprawdzamy możliwe scenariusze ataku.
Raport i omówienie
Przekazujemy opis ustaleń, ocenę ryzyka i rekomendacje. Wyjaśniamy je zespołowi technicznemu.
Re-testy
Po wdrożeniu poprawek sprawdzamy je ponownie na wcześniej uzgodnionych zasadach.
Pytania przed testem
Co warto wiedzieć przed rozmową?
Jakie informacje są potrzebne do wyceny?
Na początek wystarczy krótki opis systemu, powód testu i oczekiwany termin. Później dopytamy o funkcje, role, środowisko i potrzebne dostępy. Na tej podstawie określimy granice prac i przygotujemy wycenę.
Ile trwa test penetracyjny?
Czas zależy od wielkości i złożoności systemu, liczby ról oraz planowanych scenariuszy. Harmonogram przygotujemy po poznaniu systemu i granic badania.
Czym różni się ręczny pentest od skanowania?
Skaner pomaga znaleźć potencjalne problemy. Ręczny test sprawdza, czy i w jakich warunkach można je wykorzystać. Pozwala też zbadać role, przebieg operacji i zależności, których sama lista wyników skanowania nie wyjaśnia.
Czy muszę wybrać black box, grey box lub white box?
Nie. Model dobieramy do systemu i powodu testu. Black box oznacza ograniczoną wiedzę o systemie; grey box wykorzystuje uzgodniony dostęp i informacje; white box zakłada szerszy wgląd, na przykład do dokumentacji lub kodu.
Czy test może odbywać się na produkcji?
Może, jeśli wcześniej ustalimy dopuszczalne działania i zabezpieczenia organizacyjne. Przy środowisku produkcyjnym omawiamy możliwy wpływ na usługi, okna prac, osoby kontaktowe i sposób reagowania na zakłócenia.
Co dzieje się po przekazaniu raportu?
Omawiamy ustalenia z zespołem technicznym. Po wdrożeniu poprawek pozostajemy z klientem do zakończenia uzgodnionych re-testów. Ich warunki i obszary określamy wspólnie.
Co stanie się po wysłaniu zapytania?
Odpowiemy, jakich informacji potrzebujemy do przygotowania propozycji. Omówimy system, powód testu, środowisko i dostęp. Dokumentację oraz dane dostępowe przekażesz później uzgodnionym, bezpiecznym kanałem.
Porozmawiajmy o teście przed wyceną.
Wystarczy opis systemu, powodu testu i oczekiwanego terminu. W odpowiedzi wskażemy informacje potrzebne do przygotowania propozycji.