(w skrócie ) – 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.

Geneza pojęcia 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.

Ślepy SSRF Osobną odmianą jest ślepy 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.

Inne protokoły i schematy 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).

Przykłady wykorzystania 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.

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.

Klasyfikacja 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.

Techniki obchodzenia zabezpieczeń 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.

Przeciwdziałanie 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.

Przypisy

Kategoria:Cyberataki Kategoria:Bezpieczeństwo sieciowe