Dostęp do obiektów i funkcji
Sprawdzamy identyfikatory obiektów, relacje między kontami i funkcje administracyjne: czy serwer konsekwentnie odmawia dostępu poza uprawnieniami?
Bezpieczeństwo API
Sprawdź, czy API egzekwuje uprawnienia w całym przepływie operacji.
Badamy dostęp do obiektów i funkcji, tokeny, zmiany stanu oraz wymianę danych między usługami. Raport pokazuje, jak można nadużyć sekwencji żądań i gdzie trzeba wzmocnić kontrolę po stronie serwera.
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
O uprawnieniach decyduje zachowanie API, nie opis endpointu.
Badanie projektujemy wokół operacji, ról i danych. Test samego API lub połączenie go z aplikacją webową ustalamy przed rozpoczęciem.
Uwierzytelnianie i autoryzacja
Analizujemy wydawanie, używanie i unieważnianie tokenów oraz egzekwowanie uprawnień w kolejnych żądaniach.
Logika i przepływy danych
Badamy zmianę kolejności żądań, powtórzenie operacji i przejścia między stanami, które mogą prowadzić do nieuprawnionego działania lub ujawnienia danych.
Wejście, błędy i integracje
Sprawdzamy parametry i komunikaty błędów oraz sposób, w jaki API przekazuje dane do powiązanych usług objętych testem.
Kiedy zaplanować test
Po zmianie ról, integracji lub kluczowych operacji.
Test ma sens przed udostępnieniem API, po zmianach w autoryzacji i integracjach, przy wymaganiach klienta lub w ramach okresowej kontroli. Wielkość i złożoność operacji wpływają na plan prac.
Co pomoże ustalić wycenę?
- Operacje i odbiorcyNajważniejsze funkcje API, role, typy danych i orientacyjna liczba endpointów.
- Integracje i środowiskoUsługi zależne, dostępność wersji testowej i oczekiwany termin.
- Specyfikacja i kontaUstalimy potrzebne materiały i role. Specyfikację oraz dane dostępowe 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ą?
Czy test API musi obejmować całą aplikację?
Nie. Możemy zbadać samo API albo połączyć je z testem aplikacji webowej. Przed rozpoczęciem określimy objęte badaniem operacje, role i powiązane usługi.
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.