Slovník pojmů

CSRF

CSRF zneužívá důvěru aplikace v přihlášenou cookie relaci. Ochrana ověřuje, že požadavek na změnu skutečně vznikl v oprávněné aplikaci, ne jen v prohlížeči uživatele.

Stručná definice

Cookie potvrzuje relaci, ne původ úmyslu uživatele.

Při CSRF útočník nepotřebuje znát heslo ani číst obsah administrace. Stačí, že oběť je v cílové aplikaci přihlášená a navštíví škodlivý web. Ten může například odeslat formulář na endpoint pro změnu e-mailu, zrušení objednávky nebo založení nového uživatele. Prohlížeč v některých situacích k požadavku automaticky přiloží cookie cílové aplikace.

Cílová aplikace proto u mutujících požadavků ověřuje další důkaz původu: nejčastěji CSRF token předaný ve formuláři či hlavičce, případně konzistentní Origin nebo Referer podle návrhu aplikace. Token není náhradou přihlášení a autorizace. Doplňuje je o otázku, zda požadavek vznikl v očekávaném uživatelském rozhraní.

Kde se používá

Každá cookie relace s akcemi měnícími stav

CSRF ochrana patří především do webového UI, které používá relaci založenou na cookies.

HTML formuláře v administraci e-shopu a interních systémů
změna hesla, e-mailu, role, adresy, platebního nastavení nebo přístupových údajů
POST, PUT, PATCH a DELETE endpointy volané přihlášeným browser klientem
AJAX požadavky, které nesou session cookie a mění data na serveru
přihlášení a odhlášení, pokud jejich tok a riziko vyžadují ochranu před login CSRF

Praktický příklad

Zrušení objednávky z administrace

Obsluha otevře detail objednávky a server spolu s formulářem vytvoří CSRF token pro akci zrušení. Při odeslání aplikace zkontroluje přihlášenou relaci, token a současně oprávnění uživatele měnit objednávku dané organizace. Teprve potom provede businessovou změnu v transakci.

Útočníkův web umí vytvořit obyčejný HTML formulář, ale nezná token svázaný s relací obsluhy. Při chybě tokenu se nic nemění a aplikace vrátí bezpečnou chybovou odpověď. CSRF token se nevkládá do URL ani do logů; není to credential pro volání API z libovolného klienta.

<form method="post" action="/orders/4812/cancel">
  <input type="hidden" name="_token"
         value="{serverem-vygenerovaný-token-pro-akci-cancel-order}">
  <button type="submit">Zrušit objednávku</button>
</form>

Jak funguje

Od zobrazení formuláře po bezpečné provedení změny

Ochrana přidává k automaticky zaslané relaci hodnotu, kterou cizí origin běžně nemůže získat.

Uživatel otevře stránku Aplikace ověří session a vytvoří nebo načte token určený pro uživatele, relaci či konkrétní zamýšlenou akci.
Formulář nebo JavaScript nese token Token se vloží do skrytého formulářového pole nebo do očekávané request hlavičky, nikoli do URL.
Prohlížeč odešle požadavek K požadavku se může přiložit session cookie. Token poskytuje dodatečný důkaz, že požadavek připravil důvěryhodný klient.
Server porovná hodnotu Middleware nebo bezpečnostní vrstva ověří token ještě před změnou dat; selhání vede k odmítnutí bez vedlejšího efektu.
Aplikace autorizuje akci Po CSRF kontrole se stále ověřuje role, tenant, vlastnictví zdroje a business pravidlo. Token nepřidává oprávnění.

Důležité pojmy

Token, cookie a původ požadavku mají odlišnou roli.

Spolehlivá ochrana nevybírá jeden název hlavičky, ale navrhuje tok pro konkrétní druh klienta a relace.

Synchronizer token

Server uloží či odvodí token vázaný na relaci a druhou kopii předá do formuláře. Při mutaci musí hodnoty odpovídat. Token se generuje kryptograficky náhodně a kontroluje se na serveru.

Double-submit cookie

Jiný vzor porovnává hodnotu v cookie a v requestu. Aby útočník nemohl obě hodnoty libovolně nastavit, potřebuje promyšlené vazby, bezpečné nastavení cookie a správně zvolený důvěryhodný kontext.

SameSite cookie

SameSite omezuje, kdy prohlížeč cookie přiloží při cross-site kontextu. Je užitečná obranná vrstva, ale závisí na režimu, navigaci a potřebách legitimního přihlášení; není jedinou CSRF obranou.

Origin a Referer

Kontrola očekávaného Originu či bezpečného Refereru může odhalit cizí původ mutace. Slouží jako doplněk či podle architektury alternativa, ale musí počítat s proxy a dokumentovaným chováním prohlížeče.

Bezpečné metody

GET, HEAD a další read-only operace nemají měnit business stav. CSRF token neospravedlňuje použití GET pro zrušení objednávky nebo změnu hesla.

Vztah k jiným ochranám

CSRF, CORS, XSS a autorizace řeší různé otázky.

Záměna těchto pojmů vede k endpointu, který sice projde jednou kontrolou, ale zůstane zranitelný jinou cestou.

Autentizace: Session cookie zjišťuje, kdo je uživatel. Právě její automatické přiložení vytváří typický CSRF vektor; autentizace tokenem v explicitní hlavičce má jiný model rizika.
CORS: CORS určuje, zda skript smí číst cross-origin odpověď. Nezastavuje nutně odeslání formuláře a nesmí se používat jako CSRF kontrola.
XSS: XSS spouští kód uvnitř důvěryhodného originu. Takový kód může přečíst token ze stránky a poslat legitimně vypadající požadavek, proto CSRF nenahradí ochranu výstupu.
RBAC: RBAC rozhoduje, zda přihlášený uživatel smí akci provést. CSRF brání podvržení úmyslu, ale nesnižuje příliš široké oprávnění administrátora.

Výhody a omezení

Ochrana funguje jen pro správně vymezený tok relace.

Přínosy

brání cizímu webu provést mutaci jen díky přiložené session cookie
dává formulářům a AJAX mutacím jednotný serverový kontrakt
v kombinaci se SameSite a Origin kontrolou přidává více nezávislých vrstev
selhání lze testovat jako odmítnutý request bez vedlejšího efektu

Rizika a chyby

spoléhat na CORS nebo skryté tlačítko místo ověření tokenu na serveru
vkládat token do URL, logů či analytických nástrojů
nechat GET měnit data a tvrdit, že CSRF se týká pouze POST formulářů
předpokládat, že CSRF token ochrání aplikaci před XSS spuštěným ve stejném originu

Kdy je nutná

Cookie-based web potřebuje ochranu u každé důležité mutace.

CSRF ochrana je výchozí součást stateful webové aplikace: administrace, zákaznický účet, objednávkový tok a interní systém mívají cookie relaci a formuláře. Framework může generování a ověřování tokenu zjednodušit, ale tým musí určit, které endpointy mění stav, co je bezpečná metoda a zda mají všechny alternativní vstupy stejnou ochranu.

Čisté machine-to-machine API s access tokenem předávaným výhradně explicitní hlavičkou nemá stejný cookie CSRF vektor. Přesto je potřeba ověřit skutečný způsob klienta: token v cookie, browser credentials nebo mix session a API může riziko vrátit. Bezpečnostní pravidlo se odvozuje od chování prohlížeče, ne od názvu endpointu.

Na co myslet

Mutace chránit konzistentně napříč UI i API.

Nejlepší ochrana je nudná a všudypřítomná: neponechává ověření tokenu na paměti každého controlleru.

zapnout frameworkový CSRF middleware pro stateful browser cesty a netvořit výjimky bez důvodu
nechat GET, HEAD a další bezpečné metody bez businessových změn
nepřenášet CSRF token v URL ani ho nezapisovat do aplikačních a analytických logů
nastavit Secure, HttpOnly a vhodný SameSite režim session cookie podle skutečného login toku
testovat platný token, chybějící token, token jiné relace i mutaci z jiného originu

Časté otázky

Kdy token chrání a kdy ne

Potřebuji CSRF token, když používám cookie session?

Pro mutující browser požadavky obvykle ano. Cookie může prohlížeč přiložit i k požadavku, který vyvolal cizí web. Token nebo jiná vhodná serverová kontrola ověřuje původ záměru.

Nahradí CORS CSRF ochranu?

Ne. CORS hlavně omezuje, zda cizí JavaScript přečte odpověď. Cizí formulář může v některých případech request odeslat i bez možnosti odpověď číst.

Stačí SameSite cookie?

SameSite významně pomáhá, ale není univerzální náhradou tokenu. Záleží na režimu cookie, navigaci, kompatibilitě a legitimních cross-site přihlašovacích tocích.

Chrání CSRF token proti XSS?

Ne. Skript spuštěný uvnitř stejného originu může token ze stránky použít. XSS se brání bezpečným výstupem, omezením nebezpečného HTML a dalšími vrstvami jako CSP.

Jak řeším backend v praxi

Bezpečnostní kontrolu spojuji s oprávněním a reálným tokem dat.

U interních systémů a e-commerce řeším ochranu formulářů, API hranice, práci s relací, role i bezpečné změny dat.

Jak používám PHP v praxi Nezávazně probrat projekt