Server-side request forgery (w skrócie SSRF) – rodzaj podatności aplikacji internetowej, pozwalającej atakującemu skłonić serwer do wysłania żądania sieciowego pod dowolnie wskazany adres. Błąd występuje wtedy, gdy aplikacja pobiera zasób spod adresu URL podanego przez użytkownika, nie sprawdzając wcześniej, dokąd ten adres prowadzi.
Nazwa nawiązuje do podatności Cross-site request forgery (CSRF), lecz mechanizm jest odmienny: w CSRF niepożądane żądanie wysyła przeglądarka ofiary, natomiast w SSRF wykonuje je sam serwer.
Żądanie wysłane przez serwer pochodzi z zaufanej pozycji w sieci wewnętrznej, dzięki czemu atakujący może ominąć zaporę sieciową i sięgnąć do usług niedostępnych z internetu. Pozwala to między innymi skanować adresy w sieci lokalnej, wymuszać zapytania DNS oraz łączyć się z usługami korzystającymi z innych protokołów, na przykład z lokalnym serwerem pocztowym SMTP.
Ataki polegające na wymuszeniu na serwerze wysłania żądania były znane, zanim ukuto dla nich osobną nazwę. Za najwcześniejszy przykład uznaje się atak SMBRelay, w którym napastnik doprowadza do wysłania żądania przez usługę.
Sam termin wprowadził w 2008 roku Deral Heiland podczas konferencji ShmooCon, w wystąpieniu Web Portals: Gateway To Information Or A Hole In Our Perimeter Defenses. Opisał w nim portale firmowe wyposażone w komponenty pobierające dane z systemów wewnętrznych, do których użytkownik nie miał bezpośredniego dostępu – przez co portal stawał się pojedynczym punktem wejścia do zasobów wewnętrznych.
Szersze opracowanie zagadnienia przedstawili w 2012 roku na konferencji Black Hat USA badacze z firmy ERPScan, którzy zebrali znane wówczas odmiany ataku i zaproponowali ich klasyfikację. Zwrócili przy tym uwagę, że SSRF nie jest samodzielną podatnością, lecz sposobem przeprowadzenia ataku z wykorzystaniem podatności już istniejącej.
Napastnik może skłonić aplikację do wysłania żądania HTTP z powrotem do serwera, na którym ona działa, przez jego interfejs pętli zwrotnej, na przykład podając jako adres zasobu http://localhost/admin. Aplikacje często traktują żądania pochodzące z tego samego komputera jako zaufane. Kontrola dostępu może być realizowana przez osobny komponent umieszczony przed serwerem aplikacji i pomijana, gdy połączenie wychodzi z samego serwera. Na potrzeby odtwarzania systemu po awarii aplikacja może dopuszczać dostęp administracyjny bez logowania dla każdego, kto łączy się z lokalnego komputera, a interfejs administracyjny może nasłuchiwać na innym porcie niż główna aplikacja, niedostępnym bezpośrednio dla użytkowników. Takie relacje zaufania często sprawiają, że SSRF staje się podatnością krytyczną.
Serwer aplikacji może też komunikować się z systemami zaplecza, do których użytkownicy nie mają bezpośredniego dostępu. Systemy te często mają nierutowalne prywatne adresy IP, a ponieważ zwykle chroni je sama topologia sieci, ich zabezpieczenia bywają słabsze.
Osobną odmianą jest ślepy SSRF (blind SSRF), w którym serwer wprawdzie wysyła żądanie pod adres wskazany przez napastnika, ale otrzymana odpowiedź nie trafia z powrotem do atakującego. Skutki bywają wtedy mniej dotkliwe, bo tą drogą nie da się wprost wydobyć danych z systemów wewnętrznych. Mimo to w części przypadków prowadzi ona aż do zdalnego wykonania kodu, na przykład gdy napastnik zdoła wykorzystać błąd w kliencie HTTP samego serwera, odpowiadając na wywołane przez siebie żądanie spreparowaną treścią.
Podatność tego rodzaju wykrywa się metodami poza pasmem. Testujący podstawia adres domeny, którą sam kontroluje, a następnie sprawdza, czy pojawi się ruch skierowany do jego serwera. Charakterystyczne jest przy tym, że często widać samo zapytanie DNS o podstawioną domenę, bez późniejszego połączenia – infrastruktura sieciowa zwykle przepuszcza ruch DNS na zewnątrz, blokując jednocześnie połączenia.
Atak nie ogranicza się do protokołu HTTP. Żądanie kierowane do podatnej aplikacji jest wprawdzie zwykle żądaniem HTTP, ale połączenie nawiązywane następnie przez serwer może posługiwać się innym protokołem – między innymi FTP, SMB lub SMTP – o ile użyta przez aplikację biblioteka go obsługuje.
Służą do tego schematy adresów inne niż http i https, na przykład file, gopher, dict, data czy phar. W zależności od zastosowanego analizatora dostępne bywają także ftp, ldap, jar, mailto i ssh2. Z tego powodu OWASP zaleca wymuszanie dozwolonego schematu przy budowaniu żądania przez aplikację.
Szczególne znaczenie ma schemat gopher, ponieważ pozwala przesłać dowolne dane zamiast z góry określonego komunikatu. Żądanie postaci gopher://172.16.0.1:3300/123456789 sprawia, że serwer nawiązuje połączenie TCP ze wskazanym adresem i portem, a następnie wysyła znaki pobrane ze ścieżki, przy czym pierwszy z nich zostaje pominięty. Pozwala to skierować dowolny pakiet warstwy aplikacji pod dowolny port dowolnego hosta osiągalnego z zaatakowanego serwera.
Metoda ta ma jednak ograniczenia: część znaków nie jest przekazywana wiernie, a w jednej sesji daje się przesłać tylko jeden pakiet, co uniemożliwia atak na protokoły wymagające wcześniejszego nawiązania połączenia.
Do przeprowadzenia ataku SSRF bywa również wykorzystywana podatność polegająca na wstrzyknięciu zewnętrznej encji do przetwarzanego dokumentu XML (XML external entity, XXE).
W środowiskach chmurowych szczególnie groźne jest odpytanie usługi metadanych instancji, dostępnej pod adresem 169.254.169.254 i zwracającej tymczasowe poświadczenia dostępowe. W ten sposób w 2019 roku wykradziono z infrastruktury banku Capital One dane ponad 100 milionów osób. Do ataku wykorzystano błędnie skonfigurowaną zaporę aplikacji webowej (WAF), którą nakłoniono do przekazywania żądań do usługi metadanych platformy AWS, wydającej serwerowi tymczasowe poświadczenia do zasobów chmury, do których ma on dostęp. Zapora miała przy tym zbyt szerokie uprawnienia, pozwalające wyświetlać wszystkie pliki w zasobnikach danych i odczytywać ich zawartość.
Podatnością tego rodzaju była również CVE-2021-26855 w Microsoft Exchange Serverze, znana pod nazwą ProxyLogon. Pozwalała nieuwierzytelnionemu napastnikowi wysyłać dowolne żądania HTTP i uwierzytelnić się jako sam serwer Exchange, a w konsekwencji sięgnąć po skrzynki pocztowe użytkowników. Wykorzystana wraz z trzema innymi błędami prowadziła do wykonania kodu na serwerze z uprawnieniami konta SYSTEM. Amerykańska baza NVD zaklasyfikowała ją jako SSRF, a CISA umieściła w katalogu podatności aktywnie wykorzystywanych przez napastników.
W katalogu słabości oprogramowania CWE, prowadzonym przez MITRE, podatność ta ma oznaczenie CWE-918. Opisano ją jako sytuację, w której serwer WWW otrzymuje od komponentu nadrzędnego adres URL lub podobne żądanie i pobiera zawartość spod tego adresu, nie upewniając się w wystarczającym stopniu, że żądanie trafi do oczekiwanego miejsca docelowego. Jako nazwę alternatywną katalog podaje XSPA (ang. Cross Site Port Attack).
W zestawieniu OWASP Top 10 z 2021 roku SSRF stanowił osobną kategorię, oznaczoną A10. W edycji z 2025 roku nie występuje już samodzielnie – został włączony do kategorii A01, obejmującej błędy kontroli dostępu, gdzie figuruje jako CWE-918 wśród wyróżnionych słabości tej grupy.
Filtry sprawdzające adres podany przez użytkownika bywają omijane na kilka sposobów.
Zapis alternatywny adresu. Ten sam adres IP daje się zapisać szesnastkowo, ósemkowo, jako pojedynczą liczbę albo w postaci mieszanej, a także zakodować znakami procentowymi. Filtr porównujący ciąg znaków z zapisem kropkowo-dziesiętnym takiego wariantu nie rozpozna. OWASP odnotowuje, że część powszechnie stosowanych bibliotek walidacyjnych jest na te warianty podatna.
Przekierowania. Aplikacja może sprawdzić podany adres, a następnie podążyć za przekierowaniem HTTP prowadzącym już pod adres wewnętrzny. Z tego powodu OWASP zaleca wyłączenie obsługi przekierowań w kliencie HTTP.
Podmiana odwzorowania nazwy. Napastnik może wskazać kontrolowaną przez siebie domenę, która w chwili sprawdzania rozwiązuje się na adres publiczny, a w momencie wysłania żądania – już na adres wewnętrzny. Mechanizm ten odpowiada technice DNS rebindingu i sprawia, że sprawdzenie samej nazwy domenowej nie chroni przed atakiem, skoro odwzorowanie ustalane jest ponownie w chwili wykonania połączenia.
Niezgodność parserów. Ten sam adres bywa różnie odczytywany przez różne implementacje. Dla ciągu http://example.com\@evil.com parser zgodny ze standardem WHATWG traktuje ukośnik wsteczny jako separator ścieżki i odczytuje nazwę hosta jako example.com, natomiast implementacja wyznaczająca ją jako fragment poprzedzający ostatni znak małpy zwróci evil.com. OWASP zaleca odrzucanie adresów, z których poszczególne parsery odczytują różne nazwy hostów, zamiast prób uzgadniania tych odczytów. Zjawisko to szerzej opisał w 2017 roku na konferencji Black Hat USA Orange Tsai. Jako źródło problemu wskazał niespójność między parserami adresów URL a mechanizmami wykonującymi żądania, a za pomocą własnego narzędzia do fuzzingu wykrył wiele nieznanych wcześniej podatności we wbudowanych bibliotekach popularnych języków programowania, w tym Pythona, PHP, Perla, Ruby, Javy i JavaScriptu, a także w programach Wget i cURL.
OWASP zaleca obronę wielowarstwową, prowadzoną równolegle na poziomie aplikacji i sieci. W warstwie aplikacji należy weryfikować wszystkie dane pochodzące od użytkownika, wymuszać schemat, port i adres docelowy według listy dozwolonych wartości, nie odsyłać klientowi surowej odpowiedzi otrzymanej z serwera docelowego oraz wyłączyć podążanie za przekierowaniami HTTP. W warstwie sieci zaleca się wydzielenie funkcji pobierania zasobów zdalnych do osobnego segmentu i takie skonfigurowanie zapory, by domyślnie odrzucała cały ruch poza niezbędnym.
OWASP odradza natomiast opieranie ochrony na liście blokowanych adresów, ponieważ napastnicy dysponują gotowymi technikami obchodzenia takich filtrów. Aplikacja musiałaby bowiem rozpoznać wszystkie adresy prywatne, adresy pętli zwrotnej i adresy link-local w obu wersjach protokołu IP. Dlatego arkusz OWASP poświęcony zapobieganiu SSRF radzi nie przyjmować od użytkownika całego adresu URL, lecz wyłącznie nazwę domeny albo adres IP, porównać otrzymaną wartość z listą dozwolonych i zbudować żądanie samodzielnie. Lista blokowanych adresów pozostaje rozwiązaniem ostatecznym, stosowanym tam, gdzie zbiór dozwolonych celów nie jest z góry znany, na przykład przy mechanizmach typu webhook. W chmurze AWS dodatkowym zabezpieczeniem przed kradzieżą poświadczeń z usługi metadanych jest przejście na IMDSv2 i wyłączenie starszej wersji IMDSv1.
W listopadzie 2019 roku AWS udostępnił drugą wersję usługi metadanych instancji (IMDSv2), w której każde żądanie jest chronione uwierzytelnieniem sesji. Oprogramowanie rozpoczyna sesję żądaniem HTTP PUT i otrzymuje tajny token, którego używa następnie jak hasła w kolejnych żądaniach. Zabezpieczenie to wykorzystuje fakt, że otwarte zapory aplikacji webowych bardzo rzadko obsługują żądania PUT. Usługa nie wydaje też tokenów żądaniom zawierającym nagłówek X-Forwarded-For, co chroni przed wykorzystaniem otwartych odwrotnych serwerów pośredniczących, a pakiety z tokenem mają domyślnie czas życia (TTL) równy 1, przez co nie mogą opuścić instancji. AWS uznał to rozwiązanie za skuteczniejsze od wymagania stałego nagłówka, ponieważ wiele podatności SSRF pozwala napastnikowi ustawiać dowolne nagłówki, i według jego analizy rzeczywistych podatności chroni ono przed zdecydowaną większością z nich. Obie wersje usługi pozostały dostępne, a AWS zalecił przejście na IMDSv2 i ograniczenie dostępu wyłącznie do tej wersji. Usługa metadanych w chmurze Microsoft Azure, aby mieć pewność, że żądania są kierowane bezpośrednio do niej, i zapobiec niezamierzonemu przekierowaniu żądań, odrzuca żądania bez nagłówka Metadata: true oraz żądania zawierające nagłówek X-Forwarded-For.