Ethical Hacking Academy · Lekcja

Znajdowanie typowych błędów

IDOR, XSS, SSRF

Lekcja 3 z 413 kroki

Znajdowanie typowych błędów to bezpłatna lekcja Ethical Hacking Academy na CoddyKit. To lekcja 3 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Ethical Hacking Academy, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Ethical Hacking Academy zawiera 4 lekcji w sumie.

Najczęstsze i najważniejsze błędy

Kilka klas podatności odpowiada za większość nagród bug bounty, ponieważ występują często i mają duży wpływ. Najpierw należy opanować te trzy:

  • IDOR — uzyskiwanie dostępu do danych innych użytkowników za pomocą przewidywalnych identyfikatorów
  • XSS — wstrzykiwanie skryptu do strony
  • SSRF — zmuszanie serwera do pobrania adresów URL wybranych przez atakującego

W tej lekcji pokazano, jak metodycznie szukać każdej z nich.

Zrozumienie IDOR

Insecure Direct Object Reference (IDOR) występuje, gdy aplikacja używa identyfikatora podanego przez użytkownika do pobrania obiektu, nie sprawdzając, czy użytkownik jest jego właścicielem.

Wystarczy zmienić identyfikator, aby uzyskać dostęp do danych innej osoby. Jest to błąd kontroli dostępu, a nie podatność polegająca na wstrzykiwaniu.

# Your own invoice
GET /api/invoices/1001  Authorization: Bearer <your-token>

# Change the ID - do you get someone else's?
GET /api/invoices/1002  Authorization: Bearer <your-token>

Skuteczne wyszukiwanie IDOR

Aby znaleźć IDOR, należy utworzyć dwa konta i je porównać. Każde odwołanie do obiektu za pomocą identyfikatora jest potencjalnym kandydatem.

  • Przechwycić żądanie z konta A pobierające dane konta A
  • Odtworzyć je z sesją konta B, ale z identyfikatorem obiektu konta A
  • Jeśli B zobaczy dane A, jest to IDOR

Należy szukać identyfikatorów w adresach URL, treściach JSON, nagłówkach, a nawet w postaci base64 lub UUID.

# Original (account A)
POST /api/profile/update
{ "user_id": 5001, "email": "a@example.com" }

# Tamper: use account B's session, keep A's user_id
# If A's profile changes, broken object-level authorization.

Zrozumienie XSS

Cross-Site Scripting (XSS) polega na wstrzyknięciu kodu JavaScript wykonywanego w przeglądarce innego użytkownika. Wyróżnia się trzy główne typy:

  • Reflected — payload jest odsyłany w bezpośredniej odpowiedzi
  • Stored — payload jest zapisywany i wyświetlany innym użytkownikom (największy wpływ)
  • DOM-based — JavaScript po stronie klienta w niebezpieczny sposób zapisuje dane atakującego w DOM

Testowanie XSS

Najpierw należy wstrzyknąć unikalny znacznik, aby sprawdzić, gdzie i w jaki sposób dane wejściowe są odzwierciedlane, a następnie przygotować payload pasujący do kontekstu (treść HTML, atrybut lub skrypt).

To kontekst decyduje o tym, który payload pozwoli wyjść poza bieżący kontekst i wykonać kod.

# Probe reflection with a unique canary
?q=xss7391canary

# Basic HTML-context payload
<script>alert(document.domain)</script>

# Attribute breakout
" onmouseover=alert(1) x="

Wykazywanie wpływu XSS

Prosty alert(1) potwierdza wykonanie kodu, ale weryfikatorzy oczekują wykazania wpływu. Należy pokazać, co atakujący rzeczywiście mógłby wykraść lub zrobić.

  • Odczytać token CSRF lub informacje o sesji dostępne dla JavaScript
  • Wyświetlić document.domain, aby potwierdzić origin
  • W przypadku Stored XSS pokazać wykonanie payloadu na koncie ofiary

Nigdy nie należy faktycznie kraść sesji prawdziwych użytkowników — wystarczy zademonstrować tę możliwość.

Zrozumienie SSRF w aplikacjach

SSRF w kontekście bug bounty oznacza znalezienie funkcji, która pobiera kontrolowany przez Państwa adres URL. Prawdopodobnymi kandydatami są:

  • Adresy URL webhooków i callbacków
  • Generatory obrazów lub plików PDF pobierające zdalne zasoby
  • Funkcje podglądu adresów URL / rozwijania linków
  • Funkcje importowania z adresu URL

Aby wykazać wpływ, należy skierować je do wewnętrznych endpointów lub endpointów metadanych.

Potwierdzanie SSRF poza pasmem

Gdy odpowiedź nie pokazuje pobranej treści, należy użyć serwera out-of-band, aby potwierdzić, że cel wysłał żądanie. Callback z interakcją potwierdza ślepe SSRF.

Narzędzia takie jak Burp Collaborator lub interactsh udostępniają unikalny adres URL rejestrujący trafienia.

# Give the app your unique OOB URL
POST /api/webhook
{ "callback": "http://abc123.oast.fun/" }

# If abc123.oast.fun logs a DNS/HTTP hit, the server fetched it = SSRF.

Wyszukiwanie za pomocą proxy

Wszystkie trzy klasy błędów można znaleźć, przechwytując i modyfikując żądania. Proxy przechwytujące jest podstawowym narzędziem.

  • Burp Suite lub OWASP ZAP do przechwytywania i modyfikowania ruchu
  • Repeater do odtwarzania i modyfikowania pojedynczych żądań
  • Intruder/fuzzer do testowania wielu identyfikatorów lub payloadów

Dobre poznanie proxy przynosi większe korzyści niż opanowanie pojedynczej techniki.

Łączenie podatności dla większego wpływu

Największe nagrody wynikają z łączenia podatności. Podatność o średniej wadze w połączeniu z inną może stać się krytyczna.

  • SSRF sięgające metadanych chmury może prowadzić do kradzieży poświadczeń i przejęcia konta
  • IDOR ujawniający tokeny może prowadzić do całkowitego przejęcia konta
  • Stored XSS w panelu administratora może prowadzić do przejęcia konta administratora

Zawsze należy pytać: z czym można połączyć tę podatność?

Testowanie z zachowaniem ostrożności i zakresu

Te błędy dotyczą prawdziwych danych i prawdziwych użytkowników. Należy postępować etycznie:

  • Używać własnych kont testowych i nie przeglądać danych prawdziwych użytkowników poza zakresem niezbędnym do wykazania podatności
  • Unikać Stored XSS, który mógłby wykonać się u prawdziwych użytkowników; ograniczać testy do własnego konta
  • W przypadku SSRF nie zagłębiać się w systemy wewnętrzne; wykazać podstawową możliwość i zakończyć test

Odpowiedzialne wykazywanie wpływu pozwala korzystać z ochrony safe harbor.

Szybkie sprawdzenie

Logują się Państwo jako użytkownik B, odtwarzają żądanie z sesją B, ale z identyfikatorem obiektu użytkownika A, i otrzymują prywatne dane A. Jaka to podatność?

Podsumowanie: znajdowanie typowych błędów

Nauczyli się Państwo szukać trzech klas podatności o największej wartości.

  • IDOR: porównywać dwa konta, modyfikować identyfikatory obiektów i sprawdzać egzekwowanie własności
  • XSS: sprawdzać odzwierciedlanie, dopasowywać payload do kontekstu i wykazywać rzeczywisty wpływ
  • SSRF: znajdować funkcje pobierające adresy URL i potwierdzać ślepe przypadki poza pasmem
  • Łączyć podatności, aby uzyskać krytyczny wpływ (np. SSRF prowadzące do metadanych chmury)
  • Używać proxy przechwytującego i pozostawać w zakresie

Dalej: przekształcanie znalezisk w raporty, za które otrzymuje się nagrody.

Bezpłatny start

Ucz się Ethical Hacking Academy dzięki korepetycjom AI — za darmo

Pisz i uruchamiaj kod w przeglądarce, otrzymuj natychmiastową pomoc od korepetytora AI dostępnego 24/7 i kontynuuj naukę w sieci lub w aplikacji.

Kursy
31
Lekcje
111

Często zadawane pytania

Czy lekcja „Znajdowanie typowych błędów” jest bezpłatna?

Tak — pełny tekst „Znajdowanie typowych błędów” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Ethical Hacking Academy, przejdź na CoddyKit PRO. Kurs Ethical Hacking Academy zawiera 4 lekcji w sumie.

Co nauczysz się w „Znajdowanie typowych błędów”?

IDOR, XSS, SSRF Ćwiczysz Ethical Hacking Academy z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć Ethical Hacking Academy?

Nie wymagamy żadnego doświadczenia. Ethical Hacking Academy w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 3 z 4.

Ile czasu zajmuje lekcja „Znajdowanie typowych błędów”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji Ethical Hacking Academy?

Tak. Każda lekcja Ethical Hacking Academy zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

  1. Wybór celów
  2. Rozpoznanie na dużą skalę
  3. Znajdowanie typowych błędów
  4. Pisanie świetnych raportów
← Powrót do Ethical Hacking Academy