SSRF (Server-Side Request Forgery, po polsku fałszowanie żądań po stronie serwera) to podatność pozwalająca atakującemu zmusić serwer aplikacji do wysłania żądania sieciowego pod adres, który wskaże atakujący.
Mechanizm jest banalny. Aplikacja ma funkcję „pobierz zawartość spod tego adresu” – import obrazka z URL-a, podgląd linku, weryfikacja webhooka, pobranie danych z zewnętrznego API. Atakujący podstawia własny adres, a serwer posłusznie go odpytuje.
Brzmi niegroźnie. Cała siła tego ataku bierze się z jednego faktu: serwer ma dostęp do miejsc, do których Ty nie masz.
Ty jesteś na zewnątrz. Serwer jest w środku sieci – widzi bazę danych, panele administracyjne, usługi wewnętrzne i, co najgroźniejsze, usługę metadanych chmury. Wykorzystując SSRF, atakujący nie łamie żadnych zabezpieczeń. Używa Twojego serwera jako odnóża.
Klasyczny scenariusz: metadane chmury
Najgroźniejsza odmiana tego ataku i powód, dla którego SSRF przestało być ciekawostką, a stało się jednym z podstawowych narzędzi włamywacza.
Każda duża chmura udostępnia maszynom wirtualnym usługę metadanych pod adresem lokalnym 169.254.169.254. Maszyna pobiera stamtąd swoją konfigurację oraz – i tu jest sedno – tymczasowe poświadczenia dostępowe przypisanej jej roli.
Ten adres jest nieosiągalny z internetu. Ale jest doskonale osiągalny z serwera, na którym stoi Twoja aplikacja.
Sekwencja wygląda tak:
- Atakujący znajduje funkcję pobierającą adres URL podany przez użytkownika.
- Podstawia adres usługi metadanych, ze ścieżką prowadzącą do poświadczeń roli.
- Serwer wykonuje żądanie i zwraca odpowiedź – klucz dostępowy, klucz tajny i token sesji.
- Atakujący używa tych poświadczeń z dowolnego miejsca na świecie, robiąc wszystko, na co pozwala rola przypisana maszynie.
Z podatności wyglądającej na drobiazg robi się przejęcie konta w chmurze.
Capital One, 2019 – przypadek podręcznikowy
Najgłośniejsza ilustracja tego mechanizmu.
Atakujący wykorzystał podatność SSRF w błędnie skonfigurowanej zaporze aplikacyjnej działającej na maszynie w chmurze. Skierował żądanie na usługę metadanych, pobrał tymczasowe poświadczenia roli, a następnie użył ich do wylistowania i pobrania zawartości magazynu danych.
Efekt: dane osobowe około 100 milionów wnioskodawców, ugoda opiewająca na 190 mln USD oraz osobna kara nałożona przez regulatora.
Reakcja dostawcy chmury nastąpiła szybko – niecałe trzy miesiące po ujawnieniu sprawy udostępniono drugą wersję usługi metadanych, zaprojektowaną specjalnie po to, żeby złamać ten łańcuch ataku.
Nowa wersja wymaga najpierw uzyskania tokenu sesji osobnym żądaniem typu PUT, z niestandardowym nagłówkiem. Typowa podatność SSRF pozwala wymusić proste żądanie GET i nie pozwala ani na zmianę metody, ani na dodanie nagłówków – więc krok pobrania tokenu jest dla atakującego niewykonalny. Dodatkowo odpowiedzi mają ustawiony limit przeskoków uniemożliwiający przekazanie ich dalej.
Zastrzeżenie: to działa tylko wtedy, gdy nowa wersja jest wymuszona. Maszyny uruchomione dawniej albo skonfigurowane ręcznie na starą wersję nadal istnieją i nadal są podatne.
Zmiana w klasyfikacji OWASP
Rzecz warta odnotowania, bo porządkuje terminologię.
W zestawieniu OWASP Top 10 z 2021 roku SSRF miało własną pozycję – A10. W rewizji z 2025 roku straciło samodzielny wpis i zostało włączone do kategorii Broken Access Control (naruszenie kontroli dostępu).
Uzasadnienie jest logiczne: SSRF to w istocie sytuacja, w której serwer wykonuje żądanie, do którego nie powinien być uprawniony. Nie wszyscy specjaliści zgadzają się z tym połączeniem – argumentują, że wzorce ataku i sposoby obrony są zupełnie inne. Przy naruszeniu kontroli dostępu naprawia się logikę uprawnień w aplikacji, przy SSRF filtruje się ruch wychodzący i wymusza kontrole infrastrukturalne.
Niezależnie od klasyfikacji, definicją referencyjną pozostaje wpis CWE-918.
SSRF w WordPressie
Tu robi się praktycznie, bo dotyczy każdego, kto prowadzi własną stronę.
WordPress ma sporo miejsc, w których serwer pobiera zawartość spod adresu podanego z zewnątrz:
Pingbacki i XML-RPC. Klasyczny wektor. Mechanizm pingbacków z założenia polega na tym, że Twój serwer odwiedza wskazany adres. Bywał wykorzystywany zarówno do skanowania sieci wewnętrznych, jak i do ataków rozproszonych na inne strony. Jeśli nie korzystasz z pingbacków ani z zewnętrznych aplikacji łączących się przez XML-RPC, wyłącz xmlrpc.php – to jedna z sensowniejszych rzeczy, jakie możesz zrobić dla bezpieczeństwa i wydajności.
Osadzanie treści (oEmbed). Wklejenie linku powoduje, że serwer odpytuje zdalny adres, żeby pobrać podgląd.
Import obrazków i mediów z adresu URL.
Wtyczki pobierające dane z zewnętrznych źródeł. Integracje z API, moduły pogodowe, kursy walut, kanały RSS. To najczęstsze źródło problemu, bo jakość kodu wtyczek bywa bardzo różna.
Bezpieczna funkcja, o której warto wiedzieć
Kluczowa różnica techniczna, wymagająca jednego zdania wyjaśnienia.
WordPress udostępnia dwie rodziny funkcji do wykonywania żądań HTTP. wp_remote_get() pobiera dowolny adres bez pytania. Jego bezpieczny odpowiednik wp_safe_remote_get() przepuszcza adres przez walidację, która odrzuca adresy z prywatnych i lokalnych zakresów sieciowych oraz porty spoza dozwolonej listy.
Zasada jest prosta: jeżeli adres pochodzi w jakikolwiek sposób od użytkownika – z formularza, z parametru, z ustawień wtyczki – używa się wersji bezpiecznej. Wersja zwykła nadaje się wyłącznie do adresów zapisanych na stałe w kodzie.
Jeśli piszesz własne snippety pobierające dane z zewnętrznych serwisów, warto to sprawdzić w swoim kodzie. Adres wpisany na sztywno jest bezpieczny. Adres składany z czegokolwiek, na co ma wpływ użytkownik – już nie.
Odmiany, które utrudniają obronę
SSRF ślepe (blind). Serwer wykonuje żądanie, ale nie zwraca Ci odpowiedzi. Atakujący i tak wyciąga informacje – mierząc czasy odpowiedzi albo kierując żądania na kontrolowany przez siebie serwer nasłuchujący.
Podmiana DNS (rebinding). Aplikacja sprawdza adres, dostaje poprawną odpowiedź z publicznego adresu IP i przepuszcza żądanie. Chwilę później ten sam adres domenowy rozwiązuje się już na adres wewnętrzny. Walidacja przed rozwiązaniem nazwy jest niewystarczająca – trzeba sprawdzać także po nim.
Przekierowania. Aplikacja pobiera bezpieczny adres, który zwraca przekierowanie na adres wewnętrzny. Jeśli klient HTTP automatycznie podąża za przekierowaniami, cała walidacja idzie na marne.
Obchodzenie czarnych list. Blokowanie samych ciągów localhost i 127.0.0.1 nie działa. Ten sam adres da się zapisać dziesiątkami sposobów – zapisem dziesiętnym, ósemkowym, szesnastkowym, przez skrócone formy, przez domeny rozwiązujące się na adresy lokalne.
Wniosek: czarne listy w tej dziedzinie po prostu nie działają. Działają tylko białe listy.
Jak się bronić
Sześć warstw, od najskuteczniejszej.
1. Biała lista adresów docelowych. Jeżeli aplikacja ma pobierać dane z trzech konkretnych serwisów, wpisz je na sztywno. Nie waliduj tego, co przyszło – dopuść tylko to, co znasz.
2. Blokada zakresów prywatnych i lokalnych. Rozwiąż nazwę domenową, sprawdź uzyskany adres i odrzuć zakresy prywatne oraz adres usługi metadanych. Sprawdzenie musi nastąpić po rozwiązaniu nazwy, żeby nie dało się go obejść podmianą DNS.
3. Wymuszenie nowej wersji usługi metadanych. W środowiskach chmurowych to jednorazowa zmiana konfiguracji, która zamyka najgroźniejszy wariant ataku.
4. Filtrowanie ruchu wychodzącego. Aplikacje rzadko potrzebują nieograniczonego dostępu na zewnątrz. Domyślna odmowa i wyjątki dla konkretnych celów są znacznie skuteczniejsze niż jakakolwiek walidacja w kodzie.
5. Zakaz podążania za przekierowaniami przy pobieraniu adresów pochodzących od użytkownika.
6. Minimalne uprawnienia. Jeśli poświadczenia serwera pozwalają tylko na to, czego naprawdę potrzebuje, ich kradzież jest mniej dotkliwa. To ta sama zasada, która każe ograniczać uprawnienia kluczy API na giełdzie.
Zwróć uwagę na kolejność: najskuteczniejsze zabezpieczenia leżą w infrastrukturze, nie w kodzie aplikacji. To dlatego SSRF utrzymuje się na listach największych zagrożeń od lat – walidacja adresów w kodzie jest krucha, sposobów obejścia jest mnóstwo, a trwałe rozwiązania wymagają zmian na poziomie sieci.
Cztery mity
Mit 1: „Mam małą stronę, nikt nie będzie tego szukał.” Skanowanie internetu w poszukiwaniu podatnych instancji jest zautomatyzowane i nie wybiera celów. Nikt Cię nie szuka – szuka się dowolnego podatnego serwera.
Mit 2: „Zablokowałem localhost, jest bezpiecznie.” Czarne listy w SSRF nie działają. Liczba sposobów zapisania tego samego adresu jest praktycznie nieograniczona.
Mit 3: „Nie zwracam użytkownikowi odpowiedzi, więc problem nie istnieje.” Wariant ślepy pozwala wyciągać informacje przez czasy odpowiedzi i przez żądania kierowane na zewnętrzny serwer atakującego.
Mit 4: „To problem wyłącznie dużych systemów w chmurze.” Najczęstszym wektorem jest zwykła funkcja „pobierz zawartość spod adresu”, obecna w tysiącach wtyczek i drobnych integracji.
Co zapamiętać
SSRF to podatność pozwalająca zmusić serwer do wysłania żądania pod adres wskazany przez atakującego. Jej siła bierze się z tego, że serwer ma dostęp sieciowy, którego atakujący nie ma.
Trzy rzeczy ponad resztą:
Najgroźniejszym celem jest usługa metadanych chmury pod adresem 169.254.169.254. Stamtąd wyciekają poświadczenia roli – tak wyglądał atak na Capital One w 2019 roku, kosztujący około 100 milionów rekordów i 190 mln USD ugody.
Czarne listy nie działają, białe działają. Dopuszczaj tylko znane adresy docelowe i sprawdzaj adres po rozwiązaniu nazwy, żeby nie dało się go podmienić.
W WordPressie używaj wp_safe_remote_get() wszędzie tam, gdzie adres pochodzi od użytkownika, i wyłącz xmlrpc.php, jeśli go nie potrzebujesz.
