Bezpieczeństwo Aplikacji Webowych
Zgodne z OWASP, ręcznie prowadzone, świadome logiki biznesowej.
Testowanie aplikacji webowych to dziedzina, w której przez lata spędziłem dużo czasu. OWASP Top 10 to rozsądny punkt wyjścia, ale w praktyce błędy, które powodują realne szkody, rzadko są klasycznym injection lub stored XSS — to luki logiki biznesowej, złamana kontrola dostępu i przypadki brzegowe uwierzytelniania, o których skanery automatyczne nie mogą wnioskować, ponieważ nie rozumieją, co aplikacja powinna robić.
Testuję aplikacje webowe i API zarówno w uwierzytelnionym, jak i nieuwierzytelnionym modelu zagrożeń. Oznacza to poziomą i pionową eskalację uprawnień, IDOR, race conditions, przepływy JWT i OAuth, które nie wytrzymują bliższej analizy, oraz wieloetapowe ataki, które ujawniają się tylko po spędzeniu wystarczającej ilości czasu na zrozumieniu przepływu pracy. SSRF, insecure deserialization, prototype pollution, server-side template injection — wszyscy zwykli podejrzani mają swoją kolej, ale obok pracy nad logiką, a nie zamiast niej.
W przypadku nowoczesnych stosów zajmuję się aplikacjami single-page, interfejsami API REST i GraphQL, integracjami webhooków oraz wspierającą infrastrukturą: konfiguracją CDN, CSP, CORS i nagłówkami odpowiedzi, o których ludzie zapominają, dopóki coś się nie posypie. Backendowe interfejsy API aplikacji mobilnych naturalnie wpisują się w to samo zlecenie — interesujące błędy i tak zwykle są po stronie serwera.
Raporty są pisane dla dwóch odbiorców. Deweloperzy muszą naprawić błąd, więc każde ustalenie zawiera czystą reprodukcję, przyczynę źródłową i remediation, które jest konkretne, a nie tylko „waliduj dane wejściowe”. Osoby decyzyjne muszą rozumieć ryzyko, więc podsumowanie zarządcze faktycznie podsumowuje — bez zawyżania powagi, by uzasadnić zlecenie.