OSWE i WEB-300: techniczny przewodnik po code review

OSWE i WEB-300 koncentrują się na white-box web exploitation: kandydat analizuje kod, znajduje złożoną ścieżkę podatności i przygotowuje działający exploit. Aktualny egzamin OSWE trwa 47 godzin i 45 minut, a na dokumentację są kolejne 24 godziny.

Największa zmiana względem black-box pentestu polega na tym, że źródłem prawdy nie jest tylko odpowiedź HTTP. Trzeba prześledzić dane przez routing, walidację, warstwę biznesową i sink.

Zbuduj mapę aplikacji

Pierwsze przejście przez repozytorium powinno odpowiedzieć na pięć pytań:

• gdzie definiowane są trasy i kontrolery;
• jak działa uwierzytelnianie oraz sesja;
• gdzie wykonywana jest autoryzacja obiektów;
• które funkcje dotykają plików, szablonów, XML, poleceń i bazy;
• jak aplikacja ładuje konfigurację oraz sekrety.

Uruchom aplikację lokalnie, przechwyć typowy request i powiąż go z breakpointem w kontrolerze. Statyczne wyszukiwanie bez obserwacji runtime łatwo prowadzi do fałszywych ścieżek.

Source-to-sink zamiast szukania nazw

Wyszukiwanie exec, eval lub query jest punktem startowym. Dla każdego sinka ustal, czy atakujący kontroluje dane, jakie transformacje zachodzą po drodze i czy istnieje strażnik.

Przydatny rekord ścieżki:

source: POST /import name
transform: URL decode -> regex replace
guard: role=user, extension allowlist
sink: template render / file write
control: partial after normalization

Szczególną uwagę poświęć różnicom kolejności: walidacja przed dekodowaniem, autoryzacja przed zmianą identyfikatora i regex przed normalizacją.

Klasy podatności z WEB-300

Oficjalny syllabus obejmuje m.in. omijanie ograniczeń uploadu, PHP type juggling, magic hashes, PostgreSQL extensions i UDF, bypassy regexów i znaków, SSTI, słabe tokeny, XXE, RCE przez funkcje bazy oraz command injection przez WebSocket.

Nie ucz się ich jako osobnych payloadów. Dla każdej klasy zbuduj minimalną aplikację, podatny wariant, poprawkę i test regresji. To uczy warunku, a nie ciągu znaków.

Debugger i eksperyment kontrolowany

Ustaw breakpoint przed i po walidacji oraz przy sinku. Zmieniaj jeden parametr na raz. Zapisuj typ, wartość i kodowanie na każdym etapie. W językach z luźnym typowaniem sprawdzaj również konwersję wartości i porównania.

Jeśli exploit zależy od losowości, zmierz próbkę tokenów i odtwórz generator. Jeśli używa race condition, zbierz rozkład czasu oraz warunek wyścigu zamiast zwiększać liczbę wątków bez końca.

Automatyzacja exploita

Po ręcznym potwierdzeniu przygotuj skrypt, który:

1. sprawdza dostępność i wersję celu;
2. zakłada lub uwierzytelnia sesję;
3. pobiera dynamiczne tokeny;
4. wykonuje każdy etap z kontrolą błędów;
5. waliduje rezultat niezależnym dowodem;
6. zapisuje requesty potrzebne do raportu.

Skrypt powinien przerwać działanie, gdy założenie nie jest spełnione. Exploit, który zgłasza sukces bez sprawdzenia efektu, jest gorszy niż ręczny PoC.

Plan przygotowania

Najpierw opanuj czytanie jednej technologii backendowej, potem dodaj drugą. Co tydzień analizuj mały projekt bez wskazanej podatności. Ustal limit dwóch godzin na mapę architektury i czterech na hipotezę exploitacyjną.

Ćwicz raportowanie równolegle. OSWE wymaga nie tylko znalezienia błędu, ale również reprodukowalnego opisu oraz kodu. Standard z OWASP ASVS pomaga połączyć root cause z wymaganiem naprawczym.

Gotowość do egzaminu

Jesteś gotowy, gdy potrafisz wejść w obcy projekt, uruchomić go, zmapować przepływ żądania i zbudować niezawodny exploit bez walkthrough. Znajomość nazw podatności nie wystarczy; OSWE sprawdza zdolność przejścia od kodu do działającego wpływu.

Jeśli planujesz pełną ścieżkę, zobacz porównanie OSEP, OSWE i OSED. WEB-300 warto podejmować wtedy, gdy code review jest umiejętnością używaną regularnie, a nie jednorazowym sprintem przed egzaminem.

---

Metoda śledzenia przepływu danych

Zaczynaj od wejścia kontrolowanego przez użytkownika i śledź je przez normalizację, walidację, warstwę danych oraz sink. Równolegle analizuj ścieżkę autoryzacji: kto ustala tożsamość, gdzie przypisywany jest obiekt i czy kontrola działa przy bezpośrednim wywołaniu endpointu. Zapisuj plik, funkcję, warunek i hipotezę, aby uniknąć wielokrotnego czytania tego samego kodu.

Po znalezieniu luki przygotuj minimalny, powtarzalny dowód oraz opis przyczyny źródłowej. Ćwicz w różnych językach i frameworkach, ale buduj rozpoznawanie wzorców, nie listę payloadów. Przed egzaminem sprawdź najnowszy syllabus i Exam Guide; wymagania raportu i środowiska są rozstrzygane przez dokumentację OffSec.

Źródła: WEB-300 Syllabus, OffSec OSWE Exam Guide.