SSRF (Server-Side Request Forgery)

SSRF (Server-Side Request Forgery) to podatność, w której serwer przyjmuje adres URL albo podobne żądanie od innego komponentu i pobiera jego zawartość, nie sprawdzając wystarczająco, czy żądanie trafia tam, gdzie powinno ^[2]. Atakujący nie łączy się wtedy z celem sam, tylko każe to zrobić serwerowi aplikacji. OWASP opisuje SSRF jako błąd, który występuje, gdy aplikacja pobiera zasób zdalny bez walidacji adresu podanego przez użytkownika ^[1]. MITRE podaje też nazwę alternatywną XSPA (Cross Site Port Attack) ^[2].

Jak działa

Wiele aplikacji pobiera coś z adresu podanego przez użytkownika: podgląd linku, import obrazka, webhook, kanał RSS. Jeśli adres nie jest sprawdzony, serwer staje się pośrednikiem. Według MITRE atakujący może w ten sposób ominąć zapory sieciowe (firewall), które blokują mu bezpośredni dostęp, wykonać skanowanie portów w sieci wewnętrznej, a przez schemat file:// sięgnąć do plików na serwerze ^[2]. W hierarchii CWE słabość ta jest odmianą CWE-441, czyli niezamierzonego pośrednika (confused deputy) ^[2].

Schemat poniżej pokazuje odczyt danych z usługi metadanych chmury, jeden ze scenariuszy opisanych przez OWASP ^[1].

RYS. 1SSRF do usługi metadanych

Adres 169.254.169.254 to usługa metadanych dostępna z wnętrza maszyn w chmurach AWS, Azure i GCP ^[3]. Z internetu jest niedostępna, ale z serwera aplikacji tak.

Odmiany i scenariusze

OWASP wymienia cztery typowe scenariusze ataku ^[1].

Osobną odmianą jest blind SSRF: serwer wysyła żądanie, ale atakujący nie widzi odpowiedzi. Badacze Sonar zwracają uwagę, że nawet taka odmiana pozwala na rozpoznanie sieci i dostęp do usług wewnętrznych za zaporą ^[6].

W WordPressie

Rdzeń WordPressa ma dwie rodziny funkcji HTTP. Funkcje wp_remote_get() i pokrewne wysyłają żądanie tam, gdzie wskaże kod. Funkcja wp_safe_remote_get() jest przeznaczona do żądań pod dowolne, nieznane adresy: ten adres i każdy, na który nastąpi przekierowanie, są sprawdzane przez wp_http_validate_url(), żeby uniknąć ataków SSRF ^[4]. Obsługiwane są wyłącznie protokoły http i https ^[4].

Funkcja walidująca odrzuca między innymi adresy z danymi logowania, nazwy hostów, których nie da się rozwiązać w DNS, adresy z sieci lokalnej i porty inne niż 80, 443 i 8080 ^[5]. Blokowane zakresy obejmują m.in. 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 oraz 169.254.0.0/16, opisany w kodzie jako zakres adresów link-local i metadanych chmury ^[5]. Wyjątki można dodać filtrami http_request_host_is_external i http_allowed_safe_ports ^[5].

// podatne: adres wprost od użytkownika
$r = wp_remote_get( $_POST['feed_url'] );
// bezpieczniej: walidacja adresu i przekierowań
$r = wp_safe_remote_get( esc_url_raw( $_POST['feed_url'] ) );

W praktyce SSRF w WordPressie pojawia się najczęściej w wtyczkach, które importują treści z zewnątrz, generują podglądy linków albo wysyłają webhooki i używają niesprawdzającej wersji funkcji. Filtr dodany zbyt szeroko, na przykład zezwalający na każdy host lokalny, wyłącza ochronę dla całej strony.

Zagrożenia i skutki

MITRE wymienia jako skutki SSRF odczyt danych aplikacji, wykonanie nieautoryzowanego kodu lub poleceń oraz obejście mechanizmów kontroli dostępu, takich jak zapory ^[2]. W zestawieniu CWE Top 25 za 2025 rok CWE-918 zajęło 22. miejsce ^[7]. OWASP w edycji Top 10 z 2021 roku dodał SSRF jako osobną kategorię A10 na podstawie ankiety społeczności, w której zajęło pierwsze miejsce; dane pokazywały niską częstość, ale ponadprzeciętny potencjał wykorzystania i skutków ^[1]. W edycji 2025 CWE-918 jest jedną ze słabości wymienianych w kategorii Broken Access Control (A01) ^[8].

Na współdzielonym hostingu i w chmurze SSRF bywa pierwszym krokiem do dalszego ataku. Poświadczenia odczytane z usługi metadanych mogą otworzyć dostęp do innych zasobów konta chmurowego, a usługa wewnętrzna bez uwierzytelniania, na przykład panel bazy danych, staje się osiągalna z zewnątrz.

Jak się bronić

OWASP dzieli obronę na warstwę sieci i warstwę aplikacji ^[1].

• Sieć. Wydzielenie funkcji pobierających zasoby zdalne do osobnej sieci (segmentacja sieci), reguły zapory typu „domyślnie odmawiaj” i logowanie przepływów ^[1].
• Aplikacja. Walidacja wszystkich danych od klienta, lista dozwolonych schematów, portów i celów, wyłączenie przekierowań HTTP i nieprzekazywanie klientowi surowych odpowiedzi ^[1].
• Uwaga na DNS. Trzeba uwzględnić DNS rebinding i wyścig między sprawdzeniem a użyciem adresu, czyli race condition typu TOCTOU ^[1].

OWASP wprost odradza obronę przez listę zakazanych adresów albo wyrażenia regularne, bo atakujący mają gotowe listy ładunków i narzędzia do ich obchodzenia ^[1]. Ściąga OWASP zaleca, gdy to możliwe, dopasowanie hosta do listy dozwolonych i samodzielne zbudowanie żądania, zamiast przyjmowania pełnego adresu od użytkownika; lista zakazów jest tam opisana jako ostateczność ^[3]. W AWS zaleca przejście na IMDSv2 i wyłączenie IMDSv1 ^[3]. Jako warstwę dodatkową stosuje się WAF i zasadę najmniejszych uprawnień dla konta, z którego działa serwer.

Historia i przykłady

We wrześniu 2022 roku badacze Sonar opisali niewymagający uwierzytelnienia blind SSRF w mechanizmie pingback rdzenia WordPressa, dostępnym przez XML-RPC ^[6]. Błąd polegał na wyścigu typu TOCTOU: wp_http_validate_url() rozwiązywała nazwę hosta i sprawdzała adres IP, ale samo żądanie wysyłano później, więc atakujący mógł w międzyczasie zmienić rekord DNS ^[6]. Według Sonar problem po raz pierwszy zgłoszono już w styczniu 2017 roku ^[6]. Badacze nie znaleźli ogólnego sposobu przejęcia podatnej strony bez łączenia z innymi błędami, ale wskazali ryzyko odczytu poświadczeń z usług metadanych w chmurze ^[6]. Jako obejście zalecili wyłączenie obsługi pingbacków albo zablokowanie xmlrpc.php na serwerze WWW ^[6].