Spis treściKliknij link, aby przejść do wybranego miejsca
Jak działa SSRFDlaczego serwer może zobaczyć to, czego nie widzi atakującySSRF i localhostSSRF w chmurzeGdzie najczęściej występuje SSRFDlaczego prosta weryfikacja URL nie wystarczaJak chronić się przed SSRF1. Lista dozwolonych2. Blokować prywatne adresy3. Kontrolować przekierowania4. Ograniczyć protokoły5. Izolacja sieciBlind SSRFSSRF to nie tylko "można zrobić żądanie"
Ta treść została automatycznie przetłumaczona z ukraińskiego.
Server-Side Request Forgery (SSRF) - to podatność aplikacji webowych, która pozwala atakującemu zmusić serwer do wykonania żądania HTTP do zasobu, do którego sam atakujący nie ma bezpośredniego dostępu.
Na pierwszy rzut oka może to brzmieć niezbyt niebezpiecznie: cóż, serwer wykonał żądanie HTTP. Ale problem polega na tym, że serwer często ma dostęp do wewnętrznych zasobów, które nie są dostępne w otwartym internecie.
Na przykład, do wewnętrznych API, baz danych, paneli administracyjnych lub usług metadanych w chmurze.
Jak działa SSRF
Wyobraźmy sobie prostą usługę, która pozwala na pobranie pliku z URL:
https://example.com/download?url=https://tseivo.com/image.jpg
Serwer otrzymuje adres i sam pobiera plik:
Użytkownik
│
│ URL
▼
Aplikacja webowa
│
│ Żądanie HTTP
▼
https://tseivo.com/image.jpg
To całkiem normalna funkcja.
Jednak jeśli serwer nie sprawdza przekazanego URL, użytkownik może zamiast zewnętrznej strony wskazać wewnętrzny adres:
https://example.com/download?url=http://127.0.0.1:8080/admin
Teraz żądanie do 127.0.0.1:8080 wykonuje sam serwer.
Dla atakującego może to być szczególnie interesujące, jeśli na tym porcie działa wewnętrzna usługa.
Dlaczego serwer może zobaczyć to, czego nie widzi atakujący
Wyobraźmy sobie infrastrukturę:
Internet
│
┌─────▼─────┐
│ Serwer webowy │
└─────┬─────┘
│
┌─────────┼─────────┐
▼ ▼ ▼
Wewnętrzne Baza danych Panel
API administracyjny
Z internetu dostępny jest tylko Serwer Webowy.
Jednak sam Serwer Webowy może mieć dostęp do Wewnętrznego API, bazy danych lub panelu administracyjnego.
SSRF faktycznie wykorzystuje serwer jako pośrednika:
Haker │ │ "Zrób żądanie tutaj" ▼ Serwer Webowy │ │ żądanie w imieniu serwera ▼ Wewnętrzna usługa
To znaczy, że firewall może doskonale blokować bezpośredni dostęp atakującego do Wewnętrznego API, ale SSRF pozwala obejść to ograniczenie przez serwer, który już ma wymagany dostęp.
SSRF i localhost
Jednym z najprostszych wariantów ataku jest odwołanie do localhost:
http://127.0.0.1/ http://localhost/
Lub do konkretnego portu:
http://127.0.0.1:3000/ http://127.0.0.1:8080/
To może pozwolić na uzyskanie dostępu do usług, które celowo nasłuchują tylko na lokalnym interfejsie.
Na przykład, w produkcji może działać wewnętrzny panel administracyjny:
http://127.0.0.1:8080/admin
Na zewnątrz jest niedostępny.
Jednak jeśli twoja aplikacja ma SSRF, może sama wykonać żądanie do tego panelu.
SSRF w chmurze
SSRF staje się szczególnie poważny w środowiskach chmurowych.
W niektórych platformach chmurowych serwer może zwracać się do specjalnej usługi metadanych, przez którą można uzyskać informacje o bieżącym instancie lub jego poświadczeniach.
Na przykład, aplikacja może mieć dostęp do punktu końcowego metadanych, a atakujący nie.
Jeśli atakujący znajdzie SSRF, może spróbować zmusić serwer do zwrócenia się do tego punktu końcowego.
W najgorszym przypadku może to prowadzić do uzyskania poświadczeń i dalszego dostępu do zasobów infrastruktury chmurowej.
Dlatego SSRF często postrzega się nie tylko jako problem z żądaniami HTTP, ale jako potencjalną drogę do kompromitacji całej infrastruktury.
Gdzie najczęściej występuje SSRF
SSRF warto szukać w funkcjach, gdzie serwer otrzymuje URL od użytkownika.
Na przykład:
- ładowanie obrazów z URL;
- import danych z zewnętrznego API;
- webhooki;
- sprawdzanie URL;
- generowanie podglądu strony internetowej;
- usługi PDF lub zrzutów ekranu;
- rozpakowywanie URL w czatach;
- integracje z innymi usługami;
- funkcje takie jak fetch, proxy lub download.
Na przykład, niebezpieczny kod może wyglądać bardzo prosto:
url = params[:url] response = HTTP.get(url)
Problem nie leży w HTTP.get jako takim.
Problem polega na tym, że użytkownik faktycznie uzyskał możliwość określenia, dokąd serwer będzie wysyłał żądania.
Dlaczego prosta weryfikacja URL nie wystarcza
Można pomyśleć, że wystarczy zablokować:
localhost 127.0.0.1
Jednak ochrona przed SSRF jest bardziej skomplikowana.
Istnieją różne reprezentacje adresów IP, sztuczki DNS, przekierowania i inne sposoby na obejście naiwnej weryfikacji.
Na przykład, serwer może najpierw sprawdzić domenę:
https://example.com
a następnie otrzymać przekierowanie HTTP na wewnętrzny adres.
Dlatego należy sprawdzać nie tylko URL, który użytkownik przekazał na początku, ale także ostateczny adres, do którego faktycznie nawiązywane jest połączenie.
Jak chronić się przed SSRF
Najlepsza ochrona to nie pozwalać użytkownikowi na wykonywanie dowolnych żądań po stronie serwera.
Jeśli to niemożliwe, można zastosować kilka poziomów ochrony.
1. Lista dozwolonych
Zamiast czarnej listy lepiej pozwalać tylko na znane domeny:
api.example.com images.example.com
a nie próbować wymieniać wszystkich adresów, które należy zablokować.
2. Blokować prywatne adresy
Należy blokować dostęp do:
127.0.0.0/8 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16
a także innych adresów specjalnych i lokalnych.
3. Kontrolować przekierowania
Nie należy pozwalać na:
external-site.com
↓
internal-service
Weryfikacja powinna być stosowana również do przekierowań.
4. Ograniczyć protokoły
Jeśli funkcje wystarczająco obsługują HTTP/HTTPS, nie należy pozwalać na dowolne schemy, takie jak:
file:// gopher:// ftp://
5. Izolacja sieci
Nawet jeśli SSRF się pojawi, serwer nie powinien mieć możliwości dotarcia do krytycznych wewnętrznych systemów.
To dobry przykład zasady defense in depth: nie polegać na jednym jedynym mechanizmie ochrony.
Blind SSRF
Istnieje jeszcze jeden interesujący wariant - blind SSRF.
W tym przypadku serwer wykonuje żądanie do zasobu, ale wynik nie jest zwracany atakującemu.
Na przykład:
Atakujący │ │ URL ▼ Aplikacja webowa │ │ żądanie ▼ Wewnętrzna usługa
Atakujący nie widzi odpowiedzi, ale nadal może określić, że żądanie miało miejsce, na podstawie pośrednich oznak.
Na przykład, serwer może zwrócić się do kontrolowanego przez atakującego punktu końcowego, a ten zobaczy przychodzące żądanie w swoich logach.
Blind SSRF jest trudniejszy do wykorzystania, ale nadal może stanowić poważny problem.
SSRF to nie tylko "można zrobić żądanie"
Główne niebezpieczeństwo SSRF polega na różnicy między tym, co może widzieć użytkownik, a tym, co może widzieć serwer.
Użytkownik może mieć dostęp tylko do:
Internet
a serwer - do:
Internet + Sieć wewnętrzna + localhost + Metadane w chmurze + Prywatne API
SSRF pozwala atakującemu wykorzystać te dodatkowe uprawnienia serwera.
Dlatego każda funkcja w rodzaju:
"Prześlij mi URL, a ja go pobiorę"
powinna być traktowana jako potencjalna powierzchnia ataku SSRF.
Krótko: SSRF to sytuacja, w której atakujący zmusza twój serwer do wykonywania żądań sieciowych w swoim imieniu. Im więcej wewnętrznych zasobów jest dostępnych dla serwera, tym poważniejsze mogą być konsekwencje takiej podatności.
