Co je CSRF a jak před ním chránit aplikaci
Autor: Redakce Domeny.ForSale Zveřejněno
Ve zkratce: CSRF je útok, při kterém cizí stránka přiměje prohlížeč přihlášeného uživatele odeslat nechtěný požadavek na jiný web. Pokud web ověřuje pouze to, zda je uživatel přihlášený, může provést operaci bez jeho vědomého souhlasu. Základem ochrany jsou opatření na straně aplikace: tokeny CSRF, správné nastavení cookies a kontrola původu požadavků.
Jak CSRF funguje — příklad s administrací e-shopu
CSRF je zkratka pro Cross-Site Request Forgery, tedy podvržení požadavků mezi weby. Útok využívá toho, že prohlížeč může k požadavkům směřujícím na daný web automaticky připojovat relační cookie. Díky této cookie server rozpozná přihlášeného uživatele, aniž by znovu vyžadoval heslo.
Představte si, že spravujete e-shop a máte otevřenou administraci. Na druhé kartě navštívíte stránku připravenou útočníkem. Tato stránka se pokusí do administrace odeslat požadavek na změnu e-mailové adresy přiřazené k vašemu účtu.
Pokud prohlížeč připojí relační cookie a administrace navíc neověří pravost požadavku, server jej může považovat za vaše rozhodnutí. Útočník nemusí znát heslo ani přečíst cookie — stačí, že ji prohlížeč použije při odesílání požadavku.
Je to podobné, jako kdyby někdo předložil k provedení pokyn s vaším automaticky připojeným razítkem. Systém razítko rozpozná, ale neověří, zda tuto konkrétní operaci skutečně chcete provést.
Kdy může útok uspět a co mu nezabrání
Typický útok CSRF vyžaduje několik podmínek: uživatel má aktivní relaci, prohlížeč automaticky odesílá autentizační údaje a aplikace přijímá předvídatelný požadavek, který mění stav účtu. Může jít o změnu údajů, přidání uživatele nebo smazání záznamu. Důsledky závisí na dostupných operacích a oprávněních oběti.
Útočník obvykle nepotřebuje přečíst odpověď serveru. Prohlížeč může cizí stránce zakázat čtení dat z administrace, ale samotné odeslání některých požadavků je stále možné. Proto zásada stejného původu, která omezuje přístup skriptů k cizím prostředkům, nenahrazuje ochranu před CSRF.
Ani HTTPS tento problém neřeší. Šifruje spojení a chrání přenášená data, ale nepotvrzuje, že uživatel operaci vědomě zadal. Nestačí ani samotné použití metody POST namísto GET: cizí stránka může odeslat běžný formulář metodou POST.
CSRF není totéž co XSS. Při XSS se nežádoucí kód spouští v kontextu důvěryhodného webu, zatímco CSRF zneužívá důvěru webu v požadavky z uživatelova prohlížeče. Zranitelnost XSS však může narušit ochranu před CSRF, například tím, že umožní přečíst token.
Jak zabezpečit aplikaci proti CSRF
Nejbezpečnějším výchozím bodem je vestavěná ochrana používaného frameworku. Je třeba ji zapnout a ověřit, že pokrývá všechny operace měnící data, nejen přihlašovací formulář.
- Ověřujte token CSRF. Jde o nepředvídatelnou hodnotu, kterou aplikace vloží do formuláře nebo předá k odeslání v příslušné hlavičce. Server ji před provedením operace ověří. V běžné variantě je token svázán s relací; cizí stránka by jej neměla být schopna přečíst ani uhodnout. Token by se neměl objevovat v adrese URL.
- Nastavte atribut SameSite relační cookie. Omezuje odesílání cookie v kontextech zahrnujících různé weby. Varianty Lax a Strict poskytují různou míru omezení, proto je nutné ověřit, jak zvolená varianta funguje s přihlašováním a integracemi. SameSite je jednou z vrstev ochrany, nikoli bezvýhradnou náhradou tokenu.
- Ověřujte původ požadavku. Hlavička Origin a ve vhodně navrženém mechanismu také Referer pomáhají určit, odkud požadavek pochází. Porovnávejte tento údaj s přesně stanovenými povolenými adresami, místo abyste v něm hledali jen část doménového jména.
- Neměňte data metodou GET. Otevření odkazu by nemělo smazat účet ani potvrdit objednávku. Operace měnící data by měly používat odpovídající metody a nadále podléhat kontrole CSRF.
U zvlášť citlivých úkonů přidejte opětovné ověření totožnosti nebo samostatné potvrzení. Relační cookies by také měly mít vhodně nastavené atributy Secure a HttpOnly, přestože ani jeden z nich sám o sobě CSRF nezabrání.
Potřebuje ochranu také API?
API, tedy rozhraní pro komunikaci mezi programy, může být rovněž zranitelné vůči CSRF, pokud používá relaci ověřovanou pomocí cookie. Samotná odpověď ve formátu JSON bezpečnost nezajišťuje.
Pokud klient výslovně přidává přístupový token do hlavičky Authorization a prohlížeč jej nepřipojuje automaticky, typický mechanismus CSRF se obvykle neuplatní. To však neznamená odolnost vůči krádeži tokenu nebo XSS. Ani CORS, tedy mechanismus upravující přístup mezi různými původy, není samostatnou ochranou před CSRF.
Co zkontrolovat na vlastním webu
Začněte jednou operací, například změnou e-mailové adresy. Na testovacím účtu, ve vlastním prostředí nebo se souhlasem vlastníka ověřte, zda je požadavek bez tokenu CSRF nebo s chybným tokenem odmítnut a skutečně nezmění data. Poté zkontrolujte nastavení cookie a ostatní cesty, kterými lze stejnou operaci provést.
Pokud používáte hotový systém, ověřte způsob fungování ochrany v oficiální dokumentaci k jeho verzi a nainstalovaným rozšířením. Jako uživatel chybějící zabezpečení serveru nenapravíte; riziko můžete omezit tím, že se po práci v administraci s citlivými údaji odhlásíte. Jako vlastník aplikace začněte revizí operací měnících data — právě u nich je nutné ověřovat, zda požadavek skutečně pochází z oprávněného rozhraní.
Přečtěte si také
