Pentest SSRF: metadane chmury i kontrola egress

Server-Side Request Forgery (SSRF) występuje, gdy użytkownik może wpłynąć na połączenie sieciowe wykonywane przez serwer i skierować je do miejsca nieprzewidzianego przez projektanta. Kluczowe jest słowo „serwer”: żądanie wychodzi z zaufanego środowiska aplikacji, dlatego może osiągnąć usługi wewnętrzne, panel administracyjny, płaszczyznę sterowania albo metadane instancji niedostępne bezpośrednio z Internetu.

Najkrótsza odpowiedź: dobry pentest SSRF mapuje każdy mechanizm pobierający URL, obserwuje parsowanie, DNS, redirecty i połączenie końcowe, a następnie potwierdza wpływ wyłącznie na kontrolowanym odbiorniku. W chmurze nie wolno poprzestać na filtrowaniu adresu 169.254.169.254: potrzebne są bezpieczne parsery, walidacja po rozwiązywaniu DNS, kontrola wszystkich redirectów, restrykcyjny egress oraz najmniejsze uprawnienia workload identity. IMDSv2 i nagłówki wymagane przez Azure lub GCP ograniczają część scenariuszy, ale nie zastępują usunięcia SSRF.

SSRF nie jest tylko błędem pola „pobierz obraz z URL”. Źródłem może być webhook, importer dokumentu, podgląd linku, generator PDF, skaner antywirusowy, proxy obrazów, integracja SSO, system monitoringu, callback OAuth, serwis renderujący stronę, biblioteka XML albo funkcja śledząca przekierowania. Adresy callback i redirect trzeba oceniać również według zasad z przewodnika bezpieczeństwo OAuth 2.0 i RFC 9700. Test SSRF zaczyna się od przepływu danych, a nie od listy popularnych adresów IP.

Techniczny model podatności SSRF

Bezpieczna analiza rozdziela siedem etapów, które aplikacje często traktują jako jedną operację:

źródło — parametr, plik, nagłówek, rekord w bazie lub komunikat kolejki;
parser URI — wyodrębnienie schematu, authority, userinfo, hosta, portu i ścieżki;
normalizacja — dekodowanie, IDNA, zapis IPv4/IPv6, usuwanie segmentów i domyślnych portów;
rozwiązanie nazwy — odpowiedzi A/AAAA, search domain, lokalny resolver i cache DNS;
decyzja polityki — allowlista, klasyfikacja adresu i dozwolony port;
transport — biblioteka HTTP, proxy egress, TLS, SNI i ponowne użycie połączenia;
obsługa odpowiedzi — redirect, parsowanie treści, zapis do cache lub zwrot użytkownikowi.

Jeżeli walidator i klient sieciowy nie korzystają z tej samej kanonicznej reprezentacji, pojawia się luka interpretacyjna. RFC 3986 pokazuje, że część authority może zawierać userinfo, host i port, a host może być nazwą, adresem IPv4 albo literałem IPv6. Prosty test prefiksu tekstowego nie rozumie tej składni. Wyrażenie regularne próbujące „zablokować localhost” zwykle nie obejmuje alternatywnych formatów adresu, domen rozwiązujących się lokalnie, IPv4-mapped IPv6 ani zmiany celu po redirect.

Najważniejszy model obrony brzmi: parse once, resolve, classify every address, connect to the validated destination. Polityka musi być ponownie zastosowana po każdym przekierowaniu.

Gdzie szukać sinków SSRF

Inwentaryzacja powinna łączyć przegląd funkcjonalny, kod i telemetrię egress. Typowe punkty wejścia to:

Funkcja	Dlaczego wykonuje połączenie	Częsty błąd
webhook testowy	sprawdza adres odbiorcy	dowolny host i automatyczne redirecty
import obrazu lub dokumentu	pobiera zasób użytkownika	walidacja tylko rozszerzenia pliku
podgląd linku	pobiera HTML i metadane	rozbudowany klient z obsługą wielu schematów
generator PDF/screenshot	renderuje stronę	dostęp przeglądarki do sieci wewnętrznej
integracja z API	wywołuje adres zapisany przez administratora	rola niskiego poziomu może zmienić konfigurację
parser XML/SVG	pobiera encję lub zasób pomocniczy	pośredni SSRF poza biblioteką HTTP
repozytorium lub paczka	klonuje URL i pobiera zależności	dodatkowe protokoły oraz dane uwierzytelniające

Szukaj wywołań klientów HTTP, DNS i socketów, ale również bibliotek konwersji dokumentów, headless browserów, narzędzi multimedialnych oraz systemów kolejkowych. URL może zostać zapisany dziś i pobrany asynchronicznie przez inny mikroserwis jutro. Taki „second-order SSRF” łatwo umyka testowi opartemu wyłącznie na odpowiedzi HTTP.

Pełna inwentaryzacja endpointów jest częścią pentestu API REST, GraphQL i OAuth. SSRF odpowiada kategorii API7 w OWASP API Security Top 10, ale praktyczny wpływ zależy od sieci i tożsamości procesu.

Dlaczego metadane chmurowe są tak ważne

Usługa metadanych udostępnia procesom na maszynie informacje o instancji, a często także mechanizm uzyskania krótkotrwałych poświadczeń workloadu. Osiągnięcie endpointu nie zawsze oznacza kradzież klucza; zakres zależy od dostawcy, konfiguracji, metody i nagłówków, a przede wszystkim od uprawnień przypisanej tożsamości.

AWS EC2 i IMDSv2

AWS udostępnia IMDS lokalnie pod adresem link-local. W dokumentacji opcji metadanych EC2 opisano tryb IMDSv2, w którym token jest wymagany, oraz konfigurowalny hop limit odpowiedzi. Utworzenie sesji IMDSv2 wymaga osobnego żądania PUT, a kolejne zapytania muszą nieść token. To blokuje wiele prostych sinków SSRF, które potrafią wykonać tylko GET bez kontrolowanych nagłówków.

Nie jest to jednak ogólna naprawa SSRF. Jeżeli podatna funkcja pozwala zmieniać metodę i nagłówki albo wykonanie kodu następuje wewnątrz workloadu, IMDS może nadal być osiągalny. Najlepsza konfiguracja to HttpTokens=required, rozważne ustawienie hop limitu, wyłączenie IMDS tam, gdzie jest zbędny, lokalne ograniczenie dostępu oraz minimalna rola IAM.

Azure Instance Metadata Service

Azure IMDS wymaga nagłówka Metadata: true i odrzuca żądania zawierające X-Forwarded-For. Microsoft podkreśla jednocześnie, że IMDS jest dostępny dla procesów na VM i nie powinien być traktowany jako kanał bezpiecznego przechowywania sekretów. W nowszych architekturach warto ocenić również Metadata Security Protocol, lokalne reguły zapory i tożsamość zarządzaną przypisaną do maszyny.

Google Compute Engine

Zapytania do Google Cloud metadata wymagają nagłówka Metadata-Flavor: Google; dokumentacja odpytywania metadanych wskazuje też automatyczne odrzucanie żądań z X-Forwarded-For. Podobnie jak u innych dostawców, najważniejszą granicą wpływu jest konto usługi i jego role. Zbyt szeroka tożsamość sprawia, że pojedynczy błąd aplikacji staje się drogą do zasobów projektu.

Różnic między platformami nie wolno upraszczać do jednego payloadu. Profesjonalny pentest chmury AWS, Azure i GCP łączy test aplikacji z oceną IAM, sieci, metadanych i logów control plane.

Zasady bezpiecznego, autoryzowanego testu SSRF

Przed testem ustal dozwolone odbiorniki, protokoły, porty, wolumen i dane. Nie skanuj sieci wewnętrznej przez podatny serwer bez osobnej zgody. Nie odczytuj sekretów z metadanych tylko po to, aby „wzmocnić” dowód. W większości przypadków wystarcza kontrolowany callback, log DNS/HTTP oraz nieszkodliwe pole identyfikujące instancję.

Bezpieczna infrastruktura testowa powinna zawierać:

domenę-canary z kontrolowanymi rekordami A i AAAA;
serwer rejestrujący DNS, TCP, TLS i HTTP bez przechowywania zbędnych danych;
atrapę usługi metadanych w stagingu, która zwraca tylko syntetyczne wartości;
dedykowane konto i tenant bez danych produkcyjnych;
korelacyjny identyfikator dla każdej próby;
regułę stop, jeżeli pojawi się dostęp do nieprzewidzianego segmentu albo sekretu.

W środowisku produkcyjnym potwierdź najmniejszy możliwy efekt. Jeżeli obserwujesz callback z backendu, a polityka zakazuje dowolnego egress, to jest już mocny dowód. Nie ma potrzeby przechodzenia do panelu wewnętrznego.

Metodyka pentestu SSRF krok po kroku

1. Zbuduj katalog funkcji wykonujących połączenia

Połącz dokumentację OpenAPI, ruch aplikacji, wyszukiwanie w kodzie, konfigurację kolejek i logi proxy egress. Dla każdego sinku zapisz: źródło URL, proces wykonujący połączenie, obsługiwane schematy, metody i nagłówki, redirecty, resolver, proxy, timeout, limit odpowiedzi i sposób prezentowania wyniku.

Przetestuj role i granice tenantów. Czasem sam fetcher jest poprawnie ograniczony, ale nieuprawniony użytkownik może edytować URL należący do integracji administratora. To połączenie SSRF z błędem autoryzacji obiektowej.

2. Ustal zachowanie klienta na kontrolowanym serwerze

Na własnej domenie sprawdź, czy aplikacja wykonuje DNS, który adres wybiera, jakie wysyła nagłówki, czy używa proxy, czy śledzi redirect i jak długo czeka. Użyj unikalnych ścieżek, aby odróżnić próby. Kontrolowany odbiornik pozwala odpowiedzieć na większość pytań bez dotykania sieci wewnętrznej.

Porównaj walidację przy zapisie URL i w momencie wykonania. Jeżeli URL trafia do kolejki, pracownik może używać innej biblioteki niż API przyjmujące dane.

3. Testuj kanonikalizację i rozwiązywanie nazwy

W wydzielonym środowisku przygotuj macierz prawidłowych i odrzucanych przypadków dla schematu, userinfo, portu, nazw IDN, końcowej kropki, IPv6, IPv4-mapped IPv6 i wielu odpowiedzi DNS. Celem nie jest kolekcja trików, tylko sprawdzenie, czy jedna biblioteka parsuje i normalizuje adres przed polityką.

Każdy zwrócony przez DNS adres A i AAAA musi być sklasyfikowany. Odrzucaj loopback, link-local, private, multicast, unspecified i inne zakresy specjalne zależnie od modelu biznesowego. Zabezpieczenie musi objąć zmianę odpowiedzi DNS między walidacją a połączeniem; najlepiej połączyć się z adresem, który właśnie przeszedł kontrolę, zachowując prawidłowe SNI i weryfikację certyfikatu.

4. Oceniaj redirect jako nowe żądanie

Automatyczne przekierowanie jest częstym ominięciem dobrej walidacji pierwszego URL. Bezpieczna opcja to wyłączenie redirectów. Jeżeli funkcja ich potrzebuje, limituj liczbę hopów i dla każdego ponownie wykonuj parse, resolve, klasyfikację IP, kontrolę portu i TLS. Nie przenoś nagłówków Authorization, cookies ani własnych tokenów do innego originu.

Brak treści w odpowiedzi nie oznacza braku podatności. Monitoruj asynchroniczne DNS i HTTP przez czas odpowiadający retry kolejki. Odróżnij callback serwera od skanera bezpieczeństwa, systemu antyspamowego i przeglądarki operatora, analizując źródłowy ASN, nagłówki, czas i unikalny token.

W kodzie śledź dane od zapisu aż do konsumenta. Importer może zwrócić 202 Accepted, a właściwe pobranie wykonać godzinę później z uprzywilejowanej sieci.

6. Zweryfikuj wpływ bez pobierania sekretów

Najpierw potwierdź możliwość wyjścia do kontrolowanej domeny. Następnie, za zgodą, wykorzystaj atrapę wewnętrznego serwisu albo nieczuły endpoint diagnostyczny. W chmurze preferuj dowód konfiguracyjny: osiągalność, wymaganą metodę i nagłówki oraz zakres roli workloadu z IAM. Jeżeli trzeba wykazać dostęp do metadanych, odczytaj niesekretne pole i zatrzymaj test.

Nie używaj uzyskanych poświadczeń do kolejnych usług bez osobnego scenariusza w rules of engagement. Ocena możliwego wpływu na podstawie polityki IAM jest często wystarczająca.

Detekcja i telemetria SSRF

Skuteczna detekcja łączy warstwę aplikacji, DNS, sieć i control plane. Zbieraj:

użytkownika i funkcję, która zainicjowała pobranie;
surowy URL chroniony przed wyciekiem poświadczeń oraz jego kanoniczne komponenty;
wszystkie odpowiedzi A/AAAA i ostateczny adres połączenia;
pełny łańcuch redirectów bez sekretów;
metodę, status, rozmiar, czas i decyzję polityki egress;
zapytania do zakresów link-local i usług metadanych;
użycie tożsamości workloadu bezpośrednio po nietypowym połączeniu;
odrzucenia egress proxy oraz anomalie TLS/SNI.

Alarm o samym połączeniu do prywatnego IP może być hałaśliwy w mikroserwisach. Lepszy sygnał łączy wejście sterowane przez użytkownika, nowy cel DNS i funkcję, która normalnie komunikuje się z wąską listą hostów. Oznaczaj canary secrets i wykrywaj ich użycie, ale nie umieszczaj prawdziwych kluczy w honeypotach.

Hardening aplikacji, sieci i chmury

OWASP SSRF Prevention Cheat Sheet zaleca obronę warstwową. Najważniejsze praktyki to:

nie przyjmuj pełnego URL, jeżeli biznes wymaga tylko identyfikatora lub nazwy hosta;
stosuj allowlistę konkretnych originów, gdy zbiór odbiorców jest znany;
użyj jednej, dojrzałej biblioteki URI i porównuj kanoniczne komponenty;
ogranicz schematy do potrzebnych, zwykle https, oraz jawnie dozwolone porty;
rozwiąż DNS i sprawdź wszystkie adresy IPv4/IPv6 przed połączeniem;
wyłącz redirecty albo waliduj każdy hop od początku;
ustaw krótkie timeouty, limit pobieranych bajtów i limit dekompresji;
usuń automatyczne poświadczenia, cookies i nagłówki z żądań do obcych originów;
kieruj ruch przez uwierzytelniony proxy egress z domyślną odmową;
ogranicz NetworkPolicy, security groups i lokalną zaporę procesu;
wymagaj IMDSv2 w AWS, zastosuj mechanizmy dostawcy i blokadę lokalną tam, gdzie możliwe;
nadaj workload identity minimalne role, krótki czas życia i monitoring użycia.

Te kontrolki powinny zostać zdefiniowane już w architekturze i zweryfikowane przez OWASP ASVS 5. Sam filtr aplikacyjny bez egress policy jest pojedynczym punktem awarii; sama sieć bez bezpiecznego parsera nie odróżnia legalnego partnera od celu kontrolowanego przez atakującego.

Checklista SSRF dla inżyniera i pentestera

Źródła techniczne

Chcesz sprawdzić SSRF bez ryzyka dla produkcji? Najlepszy test łączy analizę kodu i przepływu danych, kontrolowany serwer callback, obserwowalny egress oraz przegląd ról chmurowych. Dzięki temu raport pokazuje dokładną przyczynę i realny zasięg bez skanowania cudzej sieci lub pobierania sekretów.