BEZPIECZEŃSTWO TWOJEJ APLIKACJI
Pomagam znaleźć słabe punkty aplikacji webowych, API i aplikacji desktopowych. Otrzymujesz zrozumiały raport, priorytety napraw i wskazówki dla swojego zespołu.
Najpierw rozmowa i wspólny zakres. Potem decyzja o testach.
Ryzyko · dowody · zalecenia napraw
Uzgodniona autoryzacja
Zakres przed wyceną
Wyniki z kontekstem biznesowym
01 / W CZYM POMAGAM
Przed wdrożeniem, po ważnej zmianie lub gdy Twój klient pyta o bezpieczeństwo. Wspólnie ustalamy, co warto sprawdzić w pierwszej kolejności.
Sprawdzam logowanie, uprawnienia, sesje i kluczowe procesy aplikacji. Szukam błędów, które mogą prowadzić do ujawnienia danych lub wykonania niedozwolonych operacji.
Badam sposób uwierzytelniania i dostęp do operacji oraz obiektów API. Sprawdzam, czy zmiana żądania pozwala ominąć zasady widoczne w aplikacji.
Zakres dopasowuję do systemu operacyjnego i technologii aplikacji. Może obejmować lokalne dane, komunikację z serwerem oraz mechanizmy instalacji i aktualizacji.
Dla zespołów rozwijających własny produkt oraz software house’ów, które potrzebują niezależnej oceny przed przekazaniem aplikacji klientowi.
02 / JAK PRACUJĘ
Każdy etap ma konkretny cel i rezultat. Od pierwszej rozmowy po omówienie wyników i ustalenie sposobu sprawdzenia poprawek.
Rozmawiamy o tym, jak działa produkt, kto z niego korzysta i jakie dane przetwarza. Ustalamy, czy przygotowujesz wdrożenie, odpowiadasz na wymagania klienta, czy chcesz zbadać konkretny obszar ryzyka.
Określamy aplikacje, adresy, role, środowisko i dostępne konta testowe. Przed rozpoczęciem uzgadniamy pisemną autoryzację, dozwolone działania, termin, wycenę oraz kontakt na wypadek pilnego odkrycia.
Łączę narzędzia z manualnym sprawdzaniem zachowania aplikacji. Weryfikuję wyniki, zbieram dowody i opisuję możliwy wpływ. Dla webu dobieram scenariusze z WSTG; ograniczenia i pominięte obszary odnotowuję w raporcie.
Otrzymujesz podsumowanie dla osób decyzyjnych i szczegóły techniczne dla programistów. Omawiam, co wykryto, jakie ryzyko z tego wynika oraz od których poprawek warto zacząć.
Retest pozwala sprawdzić, czy zgłoszony problem został usunięty. Jego zakres, termin i warunki ustalamy w ofercie. Nowe funkcje i zmiany wykraczające poza pierwotne badanie wyceniam osobno.
Testy wykonuję w uzgodnionych granicach. Testy obciążeniowe, socjotechnika i działania zakłócające dostępność wymagają osobnych ustaleń i nie są domyślną częścią badania aplikacji.
03 / ZAKRES BEZ NIEDOMÓWIEŃ
Checklista porządkuje obszary testów webowych. Wybieramy scenariusze odpowiednie dla architektury, funkcji i ryzyka Twojego produktu.
Rozpoznaję punkty wejścia, technologie, strukturę aplikacji i publicznie ujawniane informacje. Pozwala to dopasować kolejne testy do rzeczywistego działania produktu.
Przykłady: metadane, ujawnione ścieżki, punkty wejścia i przepływy użytkownika.
Sprawdzam konfigurację elementów udostępniających aplikację w uzgodnionym zakresie: nagłówki, metody HTTP, dostęp do plików i paneli administracyjnych.
Przykłady: dostępne kopie zapasowe, pliki konfiguracyjne, uprawnienia i ustawienia przeglądarki.
Badam rejestrację, tworzenie kont i sposób definiowania ról. Sprawdzam, czy procesy zarządzania tożsamością nie ujawniają danych lub nie pozwalają uzyskać niezamierzonego dostępu.
Przykłady: rozpoznawanie istniejących kont i przypisywanie ról.
Weryfikuję mechanizmy potwierdzania tożsamości: logowanie, zmianę i reset hasła oraz dodatkowe zabezpieczenia, jeśli występują w aplikacji.
Przykłady: obejście logowania, ograniczanie prób, konta domyślne i MFA.
Sprawdzam, czy użytkownik może odczytać dane innej osoby, wykonać operację administratora lub ominąć ograniczenia swojej roli. Wymaga to kont reprezentujących uzgodnione poziomy dostępu.
Przykłady: podmiana identyfikatora rekordu, przekroczenie uprawnień i dostęp między organizacjami.
Analizuję utrzymywanie dostępu po zalogowaniu oraz jego zakończenie. Sprawdzam zabezpieczenia cookies i tokenów, wygasanie sesji oraz wylogowanie.
Przykłady: CSRF, przejęcie lub utrwalenie sesji i obsługa JWT.
Badam, czy aplikacja bezpiecznie przetwarza dane z formularzy, parametrów i żądań. Dobór scenariuszy zależy od używanych technologii i dostępnych funkcji.
Przykłady: XSS, SQL injection, wstrzyknięcia poleceń, szablonów i żądania SSRF.
Sprawdzam, co aplikacja ujawnia w odpowiedzi na błędy i nietypowe żądania. Oceniam, czy komunikaty pomagają poznać wewnętrzne działanie systemu lub odsłaniają wrażliwe informacje.
Przykłady: ślady stosu, szczegóły zapytań i ścieżki na serwerze.
Weryfikuję sposób ochrony danych w komunikacji i zastosowane mechanizmy kryptograficzne, które można ocenić przy uzgodnionym dostępie do aplikacji.
Przykłady: ustawienia TLS, przesyłanie danych bez szyfrowania i słabe mechanizmy ochrony.
Sprawdzam, czy poprawne technicznie działania można połączyć w sposób sprzeczny z zasadami produktu. To scenariusze wymagające poznania Twoich procesów.
Przykłady: ominięcie etapów procesu, wielokrotne użycie operacji i obchodzenie limitów.
Badam zachowanie aplikacji po stronie użytkownika: skrypty, przechowywanie danych, komunikację między oknami i zasady dostępu do zasobów.
Przykłady: DOM XSS, CORS, clickjacking, WebSockets i dane w pamięci przeglądarki.
Ustalam dostępne operacje i sprawdzam dostęp do obiektów oraz funkcji, nadmierne ujawnianie danych i przyjmowane parametry. GraphQL uwzględniamy, jeśli korzysta z niego badana aplikacja.
API korzysta także ze scenariuszy dotyczących logowania, uprawnień, danych wejściowych i logiki biznesowej. Szczegółowe mapowanie zależy od przyjętej wersji checklisty.
WSTG dotyczy aplikacji webowych. Dla desktopu uzgadniamy system operacyjny, wersję programu, sposób instalacji, przechowywanie danych i komunikację. Jeśli program łączy się z API, jego testy możemy włączyć do zakresu. Specjalistyczne elementy, np. analiza binarna, wymagają odrębnego potwierdzenia.
04 / CO OTRZYMUJESZ
Wyniki powinny pomagać podjąć decyzję i wdrożyć zmianę. Dlatego łączę kontekst biznesowy ze szczegółami potrzebnymi programistom.
05 / PRZED PIERWSZĄ ROZMOWĄ
Nie musisz znać nazw podatności. Wystarczy, że opowiesz, jak działa Twoja aplikacja i co chcesz zabezpieczyć.
Od liczby funkcji i ról, złożoności procesów, zakresu API, dostępności dokumentacji oraz sposobu dostępu do aplikacji. Po rozmowie otrzymujesz propozycję zakresu, terminu i wyceny. Raport i warunki retestu są opisane w ofercie.
Krótki opis aplikacji, listę najważniejszych funkcji i ról, adres środowiska oraz konta testowe. Dokumentacja API i architektury pomaga, jeśli jest dostępna. Dostępy i dane przekazujemy dopiero uzgodnionym kanałem, po ustaleniu zasad.
Aktywne testy wiążą się z ryzykiem, dlatego przed rozpoczęciem uzgadniamy środowisko, okno testowe, ograniczenia i kontakt awaryjny. Jeśli to możliwe, korzystamy ze środowiska testowego z danymi testowymi. Badanie produkcji wymaga osobnych ustaleń.
Narzędzia pomagają wykrywać znane wzorce problemów. Manualne testy pozwalają dodatkowo sprawdzić role, logikę procesów i kontekst produktu oraz zweryfikować wyniki. Zakres obu części jest ustalany dla konkretnego zlecenia.
Checklista jest podstawą do doboru scenariuszy. Nie każdy punkt dotyczy każdej aplikacji, a dostęp lub czas mogą ograniczać badanie. Przed testami ustalamy wersję i zakres; w raporcie wskazuję ograniczenia i elementy nieobjęte oceną. Użycie WSTG nie oznacza certyfikacji OWASP.
Otrzymujesz raport z przeprowadzonego badania, zakresem i ograniczeniami. Brak wykrytych podatności oznacza brak ustaleń w danym zakresie i czasie, a nie gwarancję braku wszystkich błędów.
Przed badaniem uzgadniamy poufność, sposób przekazywania wyników oraz zasady przechowywania i usuwania materiałów. Zakres, termin i koszt retestu określamy w ofercie. Nowe funkcje mogą wymagać dodatkowych testów.
ZACZNIJMY OD TWOJEGO PRODUKTU
Nie potrzebujesz gotowej specyfikacji testów. Napisz, jaki produkt rozwijasz i co skłoniło Cię do rozmowy o bezpieczeństwie.
[email protected]Na początek wystarczy ogólny opis. Nie przesyłaj haseł, kluczy API ani danych klientów.
Otwiera program pocztowy z pytaniami do uzupełnienia.