OSWA i WEB-200: praktyczny przewodnik po egzaminie

OSWA i WEB-200 uczą praktycznego testowania aplikacji webowych bez wchodzenia jeszcze w pełny white-box poziomu OSWE. Egzamin trwa 23 godziny i 45 minut, jest nadzorowany, a na dokumentację kandydat ma kolejne 24 godziny.

Zakres umiejętności

Kandydat powinien rozumieć HTTP, sesje, uwierzytelnianie, kontrolę dostępu, injection, upload, traversal, XSS i typowe błędy logiki. Narzędzie proxy pomaga obserwować ruch, ale wynik zależy od metodycznej manipulacji żądaniem.

Buduj mapę aplikacji: role, endpointy, obiekty, identyfikatory i granice zaufania. Dla każdego requestu pytaj, co można zmienić, usunąć, powtórzyć lub wysłać jako inny użytkownik.

Workflow testu

Najpierw przejdź legalny flow jako każda rola. Następnie testuj autoryzację obiektową i funkcjonalną, walidację po stronie serwera, kodowanie oraz różnice między metodami HTTP. Oddziel wykrycie od exploita: minimalny PoC powinien pokazać wpływ bez niepotrzebnej destrukcji.

Prowadź tabelę: endpoint, parametr, rola, oczekiwana kontrola, wynik i dowód. Dzięki temu nie pomijasz podobnych funkcji i szybko budujesz raport.

Gotowość

Rozwiązuj laboratoria bez podpowiedzi i bez znajomości kategorii podatności z góry. Potrafisz znaleźć wektor na podstawie zachowania aplikacji, a nie nazwy modułu szkoleniowego.

OffSec zezwala na notatki i źródła online, lecz wyklucza bezpośrednie użycie chatbotów i LLM. Zasady sprawdź ponownie przed terminem.

OSWA jest dobrym krokiem przed OSWE. Do codziennego warsztatu dołącz OWASP ASVS, aby każdą podatność wiązać z wymaganiem naprawczym.

Systematyczna enumeracja aplikacji

Najpierw zbuduj mapę funkcji, ról i obiektów biznesowych. Przejdź aplikację jako użytkownik niezalogowany i zalogowany, zapisując endpointy, parametry, metody HTTP, typy danych oraz różnice odpowiedzi. Proxy history jest materiałem źródłowym, ale dopiero ręcznie uporządkowana mapa pokazuje, gdzie warto testować kontrolę dostępu, przetwarzanie danych i granice zaufania.

Dla każdego parametru ustal jego pochodzenie i miejsce użycia. Inaczej bada się identyfikator obiektu, inaczej fragment zapytania, nazwę pliku, adres URL pobierany przez serwer czy wartość wyświetlaną w HTML. Nie zaczynaj od losowej listy payloadów. Najpierw sformułuj hipotezę, wybierz najmniejszą zmianę wejścia i porównaj kod odpowiedzi, długość, treść, czas oraz efekt w stanie aplikacji.

Weryfikacja, a nie tylko wykrycie

Wynik skanera lub pojedynczy komunikat błędu jest tropem. Podatność potwierdzasz kontrolowanym dowodem, który pokazuje naruszenie poufności, integralności albo dostępności bez wykonywania zbędnych działań. Przy kontroli dostępu porównaj co najmniej dwa konteksty użytkownika. Przy błędach serwerowych oddziel zachowanie aplikacji od problemu sieci, cache i mechanizmów ochronnych.

Prowadź tabelę: hipoteza, żądanie bazowe, zmiana, obserwacja, wniosek i status. Odrzucone hipotezy też są wartościowe, bo zapobiegają powtarzaniu tych samych testów pod presją czasu.

Trening na czas

Podziel sesję na mapowanie, testy o najwyższym prawdopodobieństwie, głębszą analizę i końcową kontrolę dowodów. Co tydzień rozwiązuj nieznaną aplikację bez informacji o kategorii błędu. Po ćwiczeniu przeprowadź retrospektywę: które sygnały zauważyłeś za późno, gdzie proxy było nieuporządkowane i które testy nie miały jasno zdefiniowanego celu.

Przed egzaminem sprawdź również proces proctoringu, stabilność środowiska, eksport wymaganych materiałów i aktualne ograniczenia narzędzi. Techniczna wiedza nie kompensuje utraconych dowodów ani niezgodności z regulaminem.

Checklista pojedynczego endpointu

Przed zamknięciem analizy sprawdź, czy endpoint zachowuje się inaczej bez sesji, z rolą niższą i wyższą oraz dla obiektu należącego do innego użytkownika. Porównaj metodę, typ treści, brakujące i powtórzone parametry, wartości graniczne oraz identyfikatory przewidywalne. Jeżeli aplikacja wykonuje operację asynchronicznie, zweryfikuj także efekt końcowy, a nie tylko pierwszą odpowiedź HTTP.

Przy wejściach tekstowych określ kontekst użycia: HTML, JavaScript, SQL, system plików, polecenie, szablon albo żądanie wychodzące. Dla uploadu sprawdź walidację rozszerzenia, MIME, nazwy, lokalizacji i późniejszego sposobu podania pliku. Dla uwierzytelniania przeanalizuj reset hasła, zmianę e-maila, wylogowanie i unieważnienie sesji.

Na końcu zapisz jednoznaczny wynik: potwierdzone, odrzucone albo nieweryfikowalne z powodu ograniczenia. Taki status jest bardziej wartościowy niż długa lista payloadów bez wniosku.

Raz na kilka sesji zamień role: przejrzyj własne notatki jak osoba naprawiająca aplikację. Jeśli nie potrafisz wskazać dokładnego warunku podatności i bezpiecznego zachowania po poprawce, analiza jest niepełna. Ten nawyk przygotowuje nie tylko do egzaminu, lecz także do raportowania prawdziwego testu webowego.

Źródła: OffSec OSWA Exam Guide, OSWA Exam FAQ.