Co je SSRF, jak funguje a jak se mu bránit
Autor: Redakce Domeny.ForSale Zveřejněno
Stručně: SSRF (Server-Side Request Forgery) je zranitelnost, která útočníkovi umožňuje přimět aplikační server k odeslání požadavku na nezamýšlenou adresu. Server se tak může dostat ke zdrojům, které nejsou přímo dostupné z internetu, například ke službám ve vnitřní síti. Na rozdíl od CSRF, při kterém se využívá prohlížeč uživatele, u SSRF odesílá požadavek samotný server.
Jak funguje SSRF — jednoduchý příklad
Představte si aplikaci, která umožňuje přidat fotografii produktu vložením adresy obrázku. Uživatel zadá URL, tedy adresu zdroje, a server soubor stáhne a uloží do katalogu obchodu. Je to praktická funkce, aplikace ale musí ověřit, kam se skutečně připojuje.
Pokud přijímá libovolnou adresu, může útočník místo fotografie zadat službu dostupnou pouze ze sítě serveru. Aplikace se pak stává prostředníkem: odesílá požadavek tam, kam by se sám útočník nedostal. Pokud navíc získaný obsah vrací uživateli, může odhalit interní data.
Lze to přirovnat k recepčnímu, který na požádání kohokoli přináší dokumenty z uzamčených místností. Problémem není samotné přinášení dokumentů, ale to, že neověřuje, odkud je smí brát a komu je může předat.
Samotné stahování dat z adresy zadané uživatelem ještě neznamená zranitelnost. SSRF vzniká tehdy, když uživatel může nasměrovat požadavek mimo povolený rozsah a aplikace nevynucuje odpovídající omezení.
Kde se SSRF vyskytuje a jaké může mít následky
SSRF se může týkat každé funkce, která se připojuje k jinému zdroji na základě údajů ovládaných uživatelem. Typickými příklady jsou vytváření náhledů odkazů, import dokumentů, stahování obrázků a vytváření souborů PDF z webových stránek. Podobné riziko existuje u webhooků, tedy automatických oznámení odesílaných na určenou adresu.
Následky závisí na tom, k jakým zdrojům má server přístup a jak aplikace zpracovává odpověď. Mezi možné důsledky patří:
- čtení informací z interních služeb;
- zjištění, které služby jsou dostupné v síti serveru;
- přístup k metadatům cloudového prostředí, která někdy obsahují přihlašovací údaje;
- provedení operace ve službě, která neoprávněně důvěřuje provozu z vnitřní sítě.
SSRF automaticky neznamená ovládnutí celého serveru. Nebezpečí však roste, pokud má aplikace rozsáhlý přístup k síti a interní služby nevyžadují ověření identity.
Existuje také blind SSRF, tedy varianta, při níž útočník přímo nevidí odpověď získanou z cílového zdroje. To, že se obsah nezobrazuje, zranitelnost neodstraňuje: už samotné odeslání požadavku může vyvolat nežádoucí operaci nebo odhalit informace prostřednictvím chování aplikace.
SSRF a CSRF — podobné názvy, jiný mechanismus
CSRF (Cross-Site Request Forgery) spočívá v přimění prohlížeče uživatele k odeslání nechtěného požadavku do aplikace. Prohlížeč přitom může automaticky připojit údaje relace, například cookie přihlášeného uživatele. Cílem je obvykle provést operaci s jeho oprávněními.
U SSRF odesílá požadavek server a útok využívá jeho síťový přístup a případná oprávnění. Přihlášená oběť není pro tento útok sama o sobě nutná, i když zranitelná funkce může být dostupná až po přihlášení.
| Vlastnost | SSRF | CSRF |
|---|---|---|
| Kdo odesílá požadavek? | Aplikační server | Prohlížeč uživatele |
| Co se využívá? | Přístup a oprávnění serveru | Relace uživatele |
| Základní způsob ochrany | Kontrola cílů připojení a přístupu k síti | Ověřování požadavků měnících stav, mimo jiné pomocí tokenů CSRF |
Tato ochranná opatření nejsou vzájemně zaměnitelná. Token CSRF neřeší problém serveru, který stahuje data z nepovolených adres. Filtrování odchozích připojení zase nenahrazuje ochranu uživatelské relace.
Jak snížit riziko SSRF
Nejprve zjistěte, zda aplikace skutečně musí stahovat data z libovolné adresy. Pokud jde o integraci s jedinou službou, je bezpečnější uložit její adresu do konfigurace a od uživatele přijímat pouze identifikátor zdroje.
Pokud je zadávání adres nezbytné, použijte několik vrstev ochrany:
- Omezte povolené cíle. Pokud to funkce umožňuje, používejte pevně stanovený seznam důvěryhodných hostitelů, portů a protokolů. Neověřujte adresy jen vyhledáváním části textu.
- Ověřujte cílové adresy IP. Zohledněte IPv4 i IPv6 a blokujte nepovolené rozsahy včetně privátních sítí, lokálních adres a speciálních přístupových bodů ke cloudovým metadatům.
- Kontrolujte přesměrování a DNS. Zdánlivě bezpečná adresa může přesměrovat na zakázaný zdroj. Ověření musí zahrnovat skutečný cíl připojení, nejen původní URL.
- Omezte odchozí provoz. Síťová pravidla by měla aplikaci znemožnit přístup ke službám, které nepotřebuje. Nastavte také časové limity a omezení velikosti odpovědí.
Nepředávejte automaticky cookies, tokeny ani jiné přihlašovací údaje na adresy zadané uživatelem. V cloudovém prostředí si také prostudujte oficiální dokumentaci poskytovatele k ochraně služby metadat.
Kde začít s kontrolou aplikace
Sepište funkce, v nichž server stahuje data na základě adresy nebo jiné hodnoty zadané uživatelem. U každé určete povolené cíle připojení, způsob zpracování přesměrování a to, jaká data se vracejí uživateli.
Testujte výhradně ve vlastním prostředí nebo se souhlasem vlastníka. Pro začátek vyberte jednu funkci, například import obrázku, a ověřte, zda její omezení fungují i po přesměrování — nejen pro adresu zadanou do formuláře.
Přečtěte si také
