Co to jest SSRF?
Autor: Redakcja Domeny.ForSale Opublikowano
W skrócie: SSRF (Server-Side Request Forgery) to podatność, przez którą atakujący może nakłonić serwer aplikacji do wysłania żądania pod niezamierzony adres. Serwer może w ten sposób dotrzeć do zasobów niedostępnych bezpośrednio z internetu, na przykład usług w sieci wewnętrznej. W odróżnieniu od CSRF, gdzie wykorzystywana jest przeglądarka użytkownika, przy SSRF żądanie wykonuje sam serwer.
Jak działa SSRF — prosty przykład
Wyobraź sobie aplikację, która pozwala dodać zdjęcie produktu przez wklejenie adresu obrazu. Użytkownik podaje URL, czyli adres zasobu, a serwer pobiera plik i zapisuje go w katalogu sklepu. To wygodna funkcja, ale aplikacja musi sprawdzić, dokąd faktycznie się łączy.
Jeśli przyjmuje dowolny adres, atakujący może zamiast zdjęcia wskazać usługę dostępną wyłącznie z sieci serwera. Aplikacja staje się wtedy pośrednikiem: wysyła żądanie tam, gdzie sam atakujący nie mógłby się dostać. Jeżeli dodatkowo zwraca otrzymaną treść użytkownikowi, może ujawnić wewnętrzne dane.
Można to porównać do recepcjonisty, który na prośbę dowolnej osoby przynosi dokumenty z zamkniętych pomieszczeń. Problemem nie jest samo przynoszenie dokumentów, lecz brak sprawdzenia, skąd wolno je brać i komu można je przekazać.
Samo pobieranie danych z adresu podanego przez użytkownika nie oznacza jeszcze podatności. SSRF pojawia się wtedy, gdy użytkownik może skierować żądanie poza dozwolony zakres, a aplikacja nie egzekwuje odpowiednich ograniczeń.
Gdzie występuje SSRF i jakie może mieć skutki
SSRF może dotyczyć każdej funkcji, która łączy się z innym zasobem na podstawie danych kontrolowanych przez użytkownika. Typowe miejsca to generowanie podglądów linków, import dokumentów, pobieranie obrazów i tworzenie plików PDF ze stron internetowych. Podobne ryzyko występuje przy webhookach, czyli automatycznych powiadomieniach wysyłanych na wskazany adres.
Skutki zależą od tego, do jakich zasobów ma dostęp serwer oraz jak aplikacja obsługuje odpowiedź. Możliwe konsekwencje obejmują:
- odczyt informacji z wewnętrznych usług;
- rozpoznanie, które usługi są dostępne w sieci serwera;
- dostęp do metadanych środowiska chmurowego, czasem zawierających dane uwierzytelniające;
- wykonanie operacji w usłudze, która niewłaściwie ufa ruchowi z sieci wewnętrznej.
SSRF nie oznacza automatycznie przejęcia całego serwera. Niebezpieczeństwo rośnie jednak wtedy, gdy aplikacja ma szeroki dostęp do sieci, a wewnętrzne usługi nie wymagają uwierzytelnienia.
Istnieje też blind SSRF, czyli wariant, w którym atakujący nie widzi bezpośrednio odpowiedzi pobranego zasobu. Brak wyświetlonej treści nie usuwa podatności: samo wysłanie żądania może wywołać niepożądaną operację lub ujawnić informacje poprzez zachowanie aplikacji.
SSRF a CSRF — podobne nazwy, inny mechanizm
CSRF (Cross-Site Request Forgery) polega na nakłonieniu przeglądarki użytkownika do wykonania niechcianego żądania do aplikacji. Przeglądarka może przy tym automatycznie dołączyć dane sesji, na przykład ciasteczko zalogowanego użytkownika. Celem jest zwykle wykonanie operacji z jego uprawnieniami.
Przy SSRF to serwer wykonuje żądanie, a atak wykorzystuje jego dostęp sieciowy i ewentualne uprawnienia. Nie wymaga to z definicji zalogowanej ofiary, choć sama podatna funkcja może być dostępna dopiero po zalogowaniu.
| Cecha | SSRF | CSRF |
|---|---|---|
| Kto wysyła żądanie? | Serwer aplikacji | Przeglądarka użytkownika |
| Co jest wykorzystywane? | Dostęp i uprawnienia serwera | Sesja użytkownika |
| Podstawowy kierunek ochrony | Kontrola celów połączeń i dostępu do sieci | Weryfikacja żądań zmieniających stan, m.in. tokeny CSRF |
Zabezpieczenia te nie są zamienne. Token CSRF nie rozwiązuje problemu serwera pobierającego dane z niedozwolonych adresów. Z kolei filtrowanie połączeń wychodzących nie zastępuje ochrony sesji użytkownika.
Jak ograniczyć ryzyko SSRF
Najpierw ustal, czy aplikacja rzeczywiście musi pobierać dane z dowolnego adresu. Jeśli integracja dotyczy jednej usługi, bezpieczniej przechowywać jej adres w konfiguracji, a od użytkownika przyjmować jedynie identyfikator zasobu.
Gdy podawanie adresów jest konieczne, zastosuj kilka warstw ochrony:
- Ogranicz dozwolone cele. Jeśli funkcja na to pozwala, używaj zamkniętej listy zaufanych hostów, portów i protokołów. Nie sprawdzaj adresów wyłącznie przez wyszukiwanie fragmentu tekstu.
- Sprawdzaj docelowe adresy IP. Uwzględniaj IPv4 i IPv6 oraz blokuj niedozwolone zakresy, w tym sieci prywatne, adresy lokalne i specjalne punkty dostępu do metadanych chmurowych.
- Kontroluj przekierowania i DNS. Bezpiecznie wyglądający adres może przekierować do zabronionego zasobu. Weryfikacja musi obejmować rzeczywisty cel połączenia, a nie tylko początkowy URL.
- Ogranicz ruch wychodzący. Reguły sieciowe powinny uniemożliwiać aplikacji dostęp do usług, których nie potrzebuje. Ustaw też limity czasu i wielkości odpowiedzi.
Nie przekazuj automatycznie ciasteczek, tokenów ani innych danych uwierzytelniających do adresów wskazanych przez użytkownika. W środowisku chmurowym sprawdź również oficjalną dokumentację dostawcy dotyczącą ochrony usługi metadanych.
Od czego zacząć sprawdzanie aplikacji
Wypisz funkcje, w których serwer pobiera dane na podstawie adresu lub innej wartości podanej przez użytkownika. Dla każdej ustal dozwolone cele połączeń, obsługę przekierowań oraz to, jakie dane trafiają z powrotem do użytkownika.
Testy wykonuj wyłącznie we własnym środowisku lub za zgodą właściciela. Na początek wybierz jedną funkcję, na przykład import obrazu, i sprawdź, czy jej ograniczenia działają także po przekierowaniu — nie tylko dla adresu wpisanego w formularzu.
Zobacz też: Co oznacza www?
Przeczytaj także
