SSRF (Server-Side Request Forgery) to podatność, w której atakujący skłania serwer aplikacji do wysłania żądania pod adres, którego ten nie powinien odwiedzać. W chmurze takim adresem bywa usługa metadanych instancji, udostępniająca tymczasowe poświadczenia roli. Obrona łączy allow-listę celów, kontrolę ruchu wychodzącego i utwardzenie usługi metadanych.
- Na czym polega — serwer pobiera zasób spod adresu podanego z zewnątrz, nie sprawdzając dostatecznie, dokąd trafia żądanie (CWE-918, MITRE).
- Dlaczego groźny w chmurze — może ujawnić tymczasowe poświadczenia roli IAM z usługi metadanych instancji.
- Główna obrona — allow-lista hostów, wyłączone przekierowania i kontrola adresu IP po rozwiązaniu DNS (OWASP).
- Priorytet w AWS — tryb wyłącznie IMDSv2 (
HttpTokens=required), po sprawdzeniu, że nic nie korzysta z IMDSv1.
Jak działa atak SSRF
Atak SSRF polega na tym, że atakujący nie łączy się z celem bezpośrednio, lecz przekazuje adres aplikacji, a ta wysyła żądanie w jego imieniu. MITRE opisuje ten błąd jako CWE-918: serwer przyjmuje URL od komponentu wyżej i pobiera jego zawartość, nie upewniając się dostatecznie, że żądanie trafia do oczekiwanego celu. Mechanizm przebiega w trzech krokach.
- Adres z zewnątrz. Funkcja aplikacji pobiera zasób, np. obraz lub dokument, spod adresu wskazanego przez użytkownika.
- Żądanie z pozycji serwera. Serwer łączy się ze swojego miejsca w sieci, więc sięga też do usług wewnętrznych niedostępnych z internetu.
- Odpowiedź lub jej skutek. Treść wraca do atakującego albo zdradza się pośrednio, np. w komunikacie o błędzie.
W wariancie blind SSRF odpowiedź z żądania zaplecza nie wraca do atakującego (PortSwigger Web Security Academy), ale serwer i tak łączy się ze wskazanym celem.
Dlaczego SSRF jest groźny w chmurze
SSRF jest groźny w chmurze, bo maszyny wirtualne w AWS, Azure i Google Cloud mają lokalną usługę metadanych dostępną pod adresem 169.254.169.254. W AWS aplikacja pobiera z niej m.in. tymczasowe, automatycznie rotowane poświadczenia przypisanej roli IAM (AWS, dokumentacja EC2). Serwer zmuszony do odpytania tej usługi może je ujawnić.
Dostawcy zabezpieczają tę usługę nagłówkami. W IMDSv2 na AWS żądanie PUT zwraca token przekazywany w nagłówku X-aws-ec2-metadata-token. Hop limit, czyli liczba przeskoków sieciowych, które może pokonać odpowiedź z tokenem, wynosi według dokumentacji domyślnie 1 i da się go zmienić w zakresie 1–64 (AWS). Instancje z obrazów oznaczonych jako wymagające IMDSv2 startują z wartością 2, którą AWS zaleca też dla kontenerów (AWS, opcje IMDS dla nowych instancji). Azure wymaga nagłówka Metadata: true, a Google Cloud nagłówka Metadata-Flavor: Google; obie usługi odrzucają żądania z X-Forwarded-For.
| Usługa metadanych | Adres | Wymagany nagłówek lub token | X-Forwarded-For | Prosty SSRF typu GET |
|---|---|---|---|---|
| AWS IMDSv1 | 169.254.169.254 |
Brak | Nie dotyczy, brak tokenu | Może otrzymać odpowiedź |
| AWS IMDSv2 | 169.254.169.254 |
Token z żądania PUT w X-aws-ec2-metadata-token |
Token nie jest wydawany | Przy wymaganym tokenie odpowiedź 401 |
| Azure IMDS | 169.254.169.254 |
Metadata: true |
Żądanie odrzucane | Bez nagłówka odrzucony |
| Google Cloud | metadata.google.internal lub 169.254.169.254 |
Metadata-Flavor: Google |
Żądanie odrzucane automatycznie | Bez nagłówka odrzucony |
Przy ustawieniu HttpTokens=optional IMDSv1 i IMDSv2 działają na tej samej instancji równocześnie, dopóki IMDSv1 nie zostanie wyłączony; ustawienie startowe zależy od obrazu i ustawień konta. Z porównania dokumentacji wynika, że prosty SSRF, w którym atakujący kontroluje tylko adres w żądaniu GET, nie ustawi wymaganych nagłówków, dlatego najgroźniejszym scenariuszem jest instancja AWS z IMDSv1. Ochrona nagłówkowa nie pomaga jednak, gdy podatna funkcja pozwala sterować nagłówkami lub metodą żądania.
Gdzie SSRF pojawia się w aplikacjach
SSRF pojawia się zwykle w funkcjach, które „pobierają coś z adresu”. W projektach, które prowadzimy, trafiamy na ten błąd w generatorach PDF pobierających logo lub obrazy po URL i w podglądzie linków. To samo ryzyko niosą import z URL, webhooki z adresem podanym przez użytkownika i integracje typu „pobierz plik z chmury”.
Scenariusz wygląda zwykle niewinnie: generator faktur przyjmuje adres logo klienta, a serwer pobiera ten plik przed złożeniem dokumentu. Jeśli nikt nie ograniczył, dokąd serwer może się połączyć, ta sama funkcja sięgnie do każdego adresu osiągalnego z jego sieci. Podobny przypadek, mikroserwis generujący PDF z parametrem adresu zasobu, opisujemy w case study wykrycia SSRF w mikroserwisie generowania PDF. Takie funkcje łatwo przeoczyć, bo wyglądają na zwykłą obsługę plików.
Jak się bronić przed SSRF
Przed SSRF broni się warstwowo: aplikacja sama decyduje, dokąd wolno wysłać żądanie, a sieć i usługa metadanych ograniczają skutki ewentualnego błędu. Tak porządkuje to OWASP SSRF Prevention Cheat Sheet.
- Allow-lista hostów. Dopasuj host do listy dozwolonych celów i zbuduj żądanie samodzielnie, zamiast przekazywać dalej adres od użytkownika.
- Brak przekierowań. Wyłącz podążanie za przekierowaniami w kliencie HTTP.
- Kontrola po rozwiązaniu DNS. Rozwiąż nazwę samodzielnie, sprawdź docelowy adres IP i połącz się dokładnie z tym sprawdzonym adresem, co chroni przed DNS rebinding.
- Spójne parsowanie. Odrzucaj URL, którego host różne parsery odczytują inaczej.
- Segregacja sieci. Ogranicz na poziomie sieciowym, z czym serwer może się łączyć.
- IMDSv2 zamiast IMDSv1. Na AWS przejdź na IMDSv2 i wyłącz IMDSv1.
Deny-lista zawodzi, bo adres wewnętrzny można zapisać na wiele sposobów, a filtr zna tylko te przewidziane przez autora. PortSwigger opisuje omijanie takich filtrów m.in. przez nietypowy zapis adresu, domenę wskazującą na adres wewnętrzny lub przekierowanie. Jeśli deny-lista jest konieczna, OWASP wskazuje jako minimum 169.254.169.254, 127.0.0.0/8 i zakresy prywatne RFC 1918.
Co sprawdzić u siebie
Te sześć kroków zmniejsza ryzyko SSRF i ogranicza zasięg ewentualnego ataku, choć nie zastępuje testu aplikacji.
- Spisz funkcje pobierające zasób spod adresu, np. generatory PDF, podglądy linków, importy, webhooki i integracje z chmurą plików.
- Sprawdź reguły ruchu wychodzącego (egress) mikroserwisów, które przetwarzają adresy z zewnątrz, i zostaw tylko niezbędne cele.
- Na instancjach EC2 ustaw
HttpTokens=required, ale najpierw upewnij się, że agenci i aplikacje nie korzystają z IMDSv1, bo wymuszenie IMDSv2 je zepsuje. - Sprawdź hop limit odpowiedzi na PUT: wartość wyższa niż 1 powinna wynikać z realnej potrzeby, np. dostępu z kontenera, albo z ustawień obrazu wymagającego IMDSv2.
- Potwierdź, że klient HTTP w tych funkcjach ma wyłączone podążanie za przekierowaniami.
- Sprawdź, czy walidacja obejmuje docelowy adres IP po rozwiązaniu DNS i czy połączenie idzie na ten sam, sprawdzony adres, a nie tylko nazwę hosta w URL.
SSRF w OWASP Top 10 i CWE
W OWASP Top 10:2025 SSRF nie ma osobnej pozycji i należy do kategorii A01:2025 Broken Access Control. W OWASP Top 10:2021 był samodzielną kategorią A10:2021, dodaną na podstawie ankiety społeczności, w której zajął pierwsze miejsce. Kategoria miała średni wskaźnik występowania 2,72%, średnie ważone wykorzystywalności 8,28 i wpływu 6,72, czyli powyżej przeciętnej, oraz 9 503 wystąpienia i 385 CVE (OWASP, 2021).
W zestawieniu 2025 CWE Top 25 CWE-918 zajmuje 22. miejsce z wynikiem 3,36, po 19. pozycji w 2024 roku (MITRE, 2025). Więcej o kategorii, do której trafił SSRF, piszemy we wpisie o Broken Access Control, najczęściej wykrywanej kategorii OWASP, a całą listę omawiamy w przeglądzie kategorii ryzyka OWASP Top 10 w praktyce.
Najczęstsze pytania o SSRF
Czym różni się SSRF od CSRF?
W SSRF sfałszowane żądanie wysyła serwer aplikacji, który pobiera zasób spod adresu wskazanego przez atakującego i może sięgnąć do sieci wewnętrznej. W CSRF (Cross-Site Request Forgery) żądanie wysyła przeglądarka zalogowanego użytkownika, wykonując bez jego wiedzy akcję w aplikacji, w której ma aktywną sesję. Inna jest więc obrona: kontrola celów żądań serwera kontra weryfikacja pochodzenia żądań.
Czy WAF wystarczy, żeby zatrzymać SSRF?
Nie warto traktować go jako jedynej ochrony. Reguły WAF zwykle rozpoznają znane wzorce, co przypomina deny-listę, a OWASP ostrzega, że deny-listy łatwo obejść. Skuteczna obrona przed SSRF wymaga allow-listy w kodzie, który wie, dokąd żądanie ma trafić, oraz ograniczenia ruchu wychodzącego na poziomie sieci.
Czy IMDSv2 całkowicie chroni przed SSRF?
Nie. IMDSv2 wymaga tokenu przekazywanego w nagłówku i nie wydaje go wywołaniom z nagłówkiem X-Forwarded-For. AWS pisze, że te mechanizmy razem chronią przed zdecydowaną większością przeanalizowanych przez niego podatności SSRF (AWS Security Blog, 2019). IMDSv2 chroni jednak tylko usługę metadanych, nie inne usługi wewnętrzne, i nie pomaga, gdy podatna funkcja pozwala sterować metodą oraz nagłówkami.
Jak testuje się aplikację pod kątem SSRF?
Test zaczyna się od znalezienia wszystkich miejsc, w których aplikacja przyjmuje adres lub jego fragment, także w plikach i konfiguracji integracji. Następnie w autoryzowanym zakresie sprawdza się, czy serwer da się skłonić do połączenia z celem spoza dozwolonej listy, jak obsługuje przekierowania i czy ruch wychodzący oraz usługa metadanych są ograniczone.
Jak Pentestica może pomóc
Szukamy SSRF ręcznie, sprawdzając każdą funkcję, która pobiera zasób spod adresu, i to, dokąd serwer faktycznie może wysłać żądanie w sieci i w chmurze. W raporcie wskazujemy poprawki w kodzie, sieci i konfiguracji usługi metadanych. Mamy ponad 10 lat doświadczenia i setki zrealizowanych projektów. Zobacz nasze testy penetracyjne aplikacji webowych i API albo opisz swój system w konfiguratorze zakresu testu penetracyjnego.
Źródła
- CWE-918: Server-Side Request Forgery (SSRF), MITRE — definicja słabości.
- 2025 CWE Top 25 Most Dangerous Software Weaknesses, MITRE — pozycja i wynik punktowy CWE-918.
- OWASP Top 10:2021, A10 Server-Side Request Forgery (SSRF) — metryki kategorii i powód jej dodania.
- OWASP Top 10:2025, A01 Broken Access Control — kategoria, do której włączono CWE-918.
- OWASP Server-Side Request Forgery Prevention Cheat Sheet — warstwy obrony, allow-listy i minimalna deny-lista.
- Amazon EC2 User Guide: Configure the Instance Metadata Service options — IMDSv2, token sesyjny, hop limit i tryb HttpTokens=required.
- Amazon EC2 User Guide: Configure instance metadata options for new instances — domyślny hop limit 2 dla obrazów z ImdsSupport v2.0 i zalecenie dla kontenerów.
- Amazon EC2 User Guide: Retrieve security credentials from instance metadata — tymczasowe poświadczenia roli IAM.
- AWS Security Blog: Add defense in depth against open firewalls, reverse proxies, and SSRF vulnerabilities with enhancements to the EC2 Instance Metadata Service (2019) — uzasadnienie mechanizmów IMDSv2.
- Microsoft Learn: Azure Instance Metadata Service — wymagany nagłówek Metadata i odrzucanie X-Forwarded-For.
- Google Cloud: Query VM metadata — nagłówek Metadata-Flavor i odrzucanie X-Forwarded-For.
- PortSwigger Web Security Academy: Server-side request forgery (SSRF) — blind SSRF i słabości filtrów opartych na deny-listach.
Redakcja Pentestica to zespół pentesterów i konsultantów bezpieczeństwa, którzy na co dzień wykonują testy penetracyjne, testy TLPT wymagane przez DORA, red teaming i audyty bezpieczeństwa IT, a także prowadzą wdrożenia zgodności z NIS2, DORA i MiCA. Teksty na tym blogu piszemy z tej praktyki, a nie z opracowań. Każde twierdzenie o przepisie, terminie albo karze opieramy na źródle pierwotnym: dzienniku ustaw, tekście dyrektywy, komunikacie organu nadzoru. Jeśli czegoś nie da się potwierdzić, piszemy o tym wprost, zamiast powtarzać liczbę krążącą po branżowych portalach.