Odpowiedź.

Historia pytania

Wraz ze wzrostem liczby cyberataków, nacisk na testowanie bezpieczeństwa się zwiększył. Nawet dla ręcznych testerów ważne jest umiejętność znajdowania standardowych luk.

Problem

Często ręczni testerzy uważają kwestie bezpieczeństwa tylko za odpowiedzialność automatyków lub specjalistów ds. bezpieczeństwa. Prowadzi to do pominięcia podstawowych błędów, które są fatalne dla biznesu.

Rozwiązanie

Ręczne testowanie bezpieczeństwa to próba odtworzenia potencjalnych ataków z perspektywy zwykłego użytkownika:

Sprawdzanie XSS, SQL Injection, CSRF.
Manipulacje z cookie i sesją.
Próby naruszenia autoryzacji i ograniczenia praw.

Wszystkie znalezione problemy muszą być dokumentowane według szablonu „Bug Report” z szczegółowym opisem kroku, oczekiwanego i rzeczywistego wyniku, a także wskazaniem poziomu krytyczności.

Kluczowe cechy:

Wykorzystanie prostych technik ręcznych (zmiana parametrów w URL, próby wprowadzania niebezpiecznych wartości).
Sprawdzanie standardowych luk według OWASP Top 10.
Konieczność komunikacji z DevOps/Backend w celu wyjaśnienia, jak są obsługiwane błędy i jakie logi są generowane.

Pytania z haczykiem.

Czy można ręcznie wykryć wszystkie krytyczne luki w aplikacji?

Nie. Ręczne podejście pozwala znaleźć oczywiste luki, ale do pełnego pokrycia wymagane są skanery zautomatyzowane i pentest.

Czy wystarczy sprawdzić tylko formularz logowania i hasła do testu bezpieczeństwa?

Nie. Należy sprawdzać wszystkie moduły funkcjonalne, szczególnie te, które zmieniają/zapamiętują dane, interakcje z API, przesyłanie plików i operacje z uprawnieniami.

Czy tester musi znać się na żądaniach HTTP i odpowiedziach, jeśli mowa o ręcznych testach bezpieczeństwa?

Tak. Praca z narzędziami takimi jak DevTools, Postman lub Fiddler to klucz do znajdowania problemów z bezpieczeństwem ręcznie.

Typowe błędy i antywzorce

Sprawdzanie bezpieczeństwa ogranicza się do logowania i rejestracji.
Ignorowanie luk, jeśli nie uda się ich od razu wykorzystać.
Niedokumentowanie znalezionych luk w naruszeniu standardów raportowania błędów.

Przykład z życia

Negatywna sprawa

Tester sprawdził tylko logowanie do systemu pod kątem XSS, nie testując innych formularzy użytkowników oraz parametrów URL.

Plusy:

Szybko wykonany test pierwszej kolejności.

Minusy:

Przemknięta krytyczna luka w profilu użytkownika, gdzie można było przeprowadzić SQL Injection.

Pozytywna sprawa

Tester kolejno sprawdził wszystkie formularze wprowadzania, zmieniał parametry w żądaniach, szczegółowo opisał znalezione w bug raporcie, skontaktował się z DevOps w celu uzyskania porady dotyczącej obsługi błędów.