CSRF v mobilním vývoji: podstata, typy útoků a metody ochrany

Co je útok CSRF?

CSRF (Cross-Site Request Forgery) je útok, při kterém útočník vytvoří padělaný požadavek a donutí prohlížeč oběti jej odeslat na cílový server. Server požadavek provede, protože obdrží platné cookie-credentials aktuální relace uživatele. Útok je možný, protože prohlížeč automaticky přidává cookies ke každému požadavku na cílovou doménu, bez ohledu na to, ze které stránky byl požadavek odeslán. Uživatel možná ani neviděl stránku útočníka — stačí načíst skrytý <img>, <form> nebo <iframe> se škodlivým URL. CSRF nekrade data přímo — útok provádí akce jménem oběti (state-changing operations), jako je převod peněz, změna hesla nebo smazání účtu.

Které operace jsou nejzranitelnější?

Útoky CSRF jsou zaměřeny výhradně na operace měnící stav — GET požadavky s vedlejšími účinky, POST, PUT a DELETE. Například požadavek na změnu emailové adresy v osobním účtu: pokud server přijme požadavek bez ověření původu, může útočník dosadit svůj vlastní email a iniciovat reset hesla. Útok je obzvláště nebezpečný pro bankovní systémy, administrátorské panely a sociální sítě, kde jeden úkon má vážné následky. API mobilních aplikací používající cookies pro autentizaci jsou také náchylná k CSRF, pokud nepoužívají další kontroly.

Kdo je v riziku?

Jakékoli webové aplikace a API, kde autentizace je založena na cookies a server nekontroluje původ požadavku, jsou vystaveny útoku. Mobilní aplikace používající WebView pro autorizaci prostřednictvím webových formulářů jsou také zranitelné: komponenta prohlížeče automaticky odesílá cookies a útočník může injektovat škodlivý požadavek prostřednictvím načítání na pozadí. Podle HackerOne (2025) asi 12% všech zpráv o zranitelnostech ve webových aplikacích souvisí s chybějící ochranou proti CSRF.

Co dělá CSRF nebezpečným?

Hlavní charakteristikou CSRF je neviditelnost pro oběť. Uživatel možná ani netuší, že k útoku došlo: padělaný požadavek běží na pozadí a rozhraní aplikace nevykazuje známky napadení. Jediným způsobem, jak CSRF odhalit, je monitorování serverových logů nebo náhlé změny v účtu. Kromě toho se CSRF snadno kombinuje s jinými zranitelnostmi, jako je XSS nebo otevřené přesměrování, což mnohonásobně zvyšuje škody.

Jak funguje útok CSRF?

útok CSRF se skládá ze tří povinných podmínek: oběť je autorizována na cílovém webu, server používá autentizaci pomocí cookies a požadavek útočníka směřuje na URL akce. Útočník vytvoří HTML stránku s formulářem, skriptem nebo obrázkem, jehož atribut src ukazuje na cílové URL. Prohlížeč oběti tuto stránku načte a automaticky odešle požadavek na server spolu s cookies aktuální relace. Server obdrží platné cookies, nezkontroluje zdroj požadavku a provede operaci.

<!-- Příklad CSRF útoku přes skrytý formulář -->
<form action="https://bank.example.com/transfer"
      method="POST" id="csrf-form">
    <input type="hidden"
           name="toAccount"
           value="attacker-account">
    <input type="hidden"
           name="amount"
           value="10000">
</form>
<script>document.getElementById("csrf-form").submit()</script>

Po načtení stránky skript okamžitě odešle formulář. Prohlížeč připojí cookie relace uživatele k POST požadavku na bank.example.com. Server banky zkontroluje cookie, potvrdí, že je uživatel autentizován, a provede převod na účet útočníka. Oběť vidí prázdnou nebo legitimní stránku a peníze jsou již odepsány.

Role prohlížeče v CSRF

Klíčovou vlastností protokolu HTTP — chybějící vestavěná kontrola zdroje požadavku. Prohlížeč přidá cookie k požadavku, pokud se doména požadavku shoduje s doménou cookie. Útočník nepotřebuje znát obsah cookie — prohlížeč to dělá automaticky. Same-origin policy nechraní před CSRF, protože útok je zaměřen na server, nikoli na čtení odpovědi. Mechanizmy jako CORS jsou také bezmocné: CSRF požadavky obvykle nevyžadují čtení odpovědi, aby způsobily škodu.

Hlavní typy útoků CSRF

Útoky CSRF se klasifikují podle způsobu doručení škodlivého požadavku. Každý typ používá jiný HTML prvek k odeslání požadavku, ale všechny se spoléhají na automatické odesílání cookies prohlížečem. Výběr metody závisí na cílech útočníka: GET-based útoky vyžadují méně kódu, POST-based spolehlivěji obcházejí některé ochrany a XMLHttpRequest-based umožňují manipulaci s hlavičkami.

GET-based CSRF

Nejjednodušší metoda: útočník umístí na stránku <img> s URL obsahujícím parametry požadavku. Prohlížeč načte obrázek a odešle GET požadavek na server. Například <img src="https://api.example.com/delete?postId=123" /> smaže záznam, pokud server zpracovává DELETE přes GET. Navzdory zjevnému nebezpečí některá API stále používají GET pro operace mazání nebo aktualizace.

POST-based CSRF

Pokud server přijímá pouze POST požadavky, útočník vytvoří skrytý formulář s metodou POST a automaticky jej odešle prostřednictvím JavaScriptu. Formulář se nezobrazuje na obrazovce (všechny <input> mají type="hidden") a autofocus + .submit() funguje bez kliknutí uživatele. POST-based útoky nefungují, pokud server kontroluje hlavičku Content-Type, ale většina API přijímá standardní application/x-www-form-urlencoded.

XHR-based CSRF (s CORS)

XMLHttpRequest nebo Fetch API umožňují odesílat požadavky s libovolnými hlavičkami. Pokud server nastavil CORS příliš široce (Access-Control-Allow-Origin: *), útočník může odeslat jakýkoli požadavek a číst odpověď. Pro útok CSRF však čtení odpovědí není nezbytné — stačí provedení akce. Moderní prohlížeče odesílají preflight požadavek OPTIONS před nestandardními požadavky, což může zablokovat XHR-based CSRF, pokud je server správně nakonfigurován.

CSRF v mobilních aplikacích

Mobilní aplikace jsou méně náchylné k CSRF než webové stránky, protože nativní aplikace zřídka používají autentizaci pomocí cookies. Místo toho mobilní API častěji používají tokeny v hlavičce Authorization (Bearer tokeny, JWT). Existují však scénáře, kde je CSRF útok možný: WebView s webovým přihlášením, hybridní aplikace a API s cookie-based relacemi. Podle TechCrunch (2025) asi 18% veřejných API mobilních aplikací stále podporuje relační cookies.

CSRF přes WebView

Mnoho aplikací otevírá webové stránky v WebView — autorizaci přes OAuth, platební formuláře, prohlížení obsahu. WebView je úplný prohlížeč uvnitř aplikace, který ukládá relační cookies. Pokud útočník najde způsob, jak načíst své URL ve WebView (prostřednictvím otevřeného přesměrování nebo Deep Link), může provést útok CSRF stejně jako v běžném prohlížeči. Ochrana — použití Chrome Custom Tabs nebo SFSafariViewController místo WebView pro kritické operace.

CSRF v API s JWT autentizací

JWT tokeny jsou obvykle uloženy v localStorage nebo v paměti aplikace a nejsou odesílány automaticky — vývojář explicitně přidává hlavičku Authorization ke každému požadavku. To činí klasický CSRF útok nemožným. Pokud však aplikace ukládá JWT v cookie (což je vzácné, ale stává se), riziko se vrací. Dodatečná ochrana — připojení JWT ke konkrétnímu origin požadavku prostřednictvím claimu azp nebo aud, což brání použití tokenu na jiné doméně.

// Příklad serverového ověření CSRF tokenu v Express
const csrfProtection = (req, res, next) => {
    const token = req.headers['x-csrf-token'];
    if (!token || token !== req.session.csrfToken) {
        return res.status(403).json({ error: 'CSRF validation failed' });
    }
    next();
};

// Generování CSRF tokenu při přihlášení
app.post('/api/login', (req, res) => {
    const csrfToken = crypto.randomBytes(32).toString('hex');
    req.session.csrfToken = csrfToken;
    res.json({ csrfToken: csrfToken });
});

Metody ochrany proti CSRF

Moderní ochrana proti CSRF je založena na třech úrovních: serverové CSRF tokeny, atribut SameSite pro cookies a kontrola hlavičky Origin. Kombinace těchto metod poskytuje ochranu proti 99% CSRF útoků bez významného dopadu na UX. Výběr konkrétního přístupu závisí na architektuře aplikace: webové stránce stačí SameSite=Lax, API mobilní aplikace vyžaduje tokeny v hlavičkách.

CSRF tokeny (synchronizátor)

Standardní metoda: server generuje jedinečný token, připojí jej k relaci uživatele a předá jej klientovi. Klient token zahrne do každého požadavku měnícího stav (do skrytého pole formuláře nebo hlavičky X-CSRF-Token). Server porovná přijatý token s tokenem uloženým v relaci. Token musí být kryptograficky bezpečný, náhodný, dlouhý alespoň 32 bajtů a měnit se při každé relaci nebo operaci. Životnost tokenu — ne více než několik hodin.

SameSite Cookie

Atribut SameSite pro cookies omezuje odesílání cookies při cross-domain požadavcích. Hodnota Lax povoluje odesílání cookies pouze pro navigační GET požadavky nejvyšší úrovně — to stačí pro většinu webů. Strict blokuje cookies pro všechny cross-domain požadavky, včetně navigace: uživatel se bude muset znovu přihlásit při přechodu z jiného webu. Podle Chrome Platform Status (2026) je SameSite=Lax ve výchozím nastavení zapnut ve všech moderních prohlížečích, což snížilo počet CSRF útoků o 67%.

Kontrola Origin a Referer

Server může kontrolovat hlavičky Origin nebo Referer příchozího požadavku. Pokud požadavek přišel z jiné domény — je zablokován. Origin je spolehlivější než Referer, protože je vždy přítomen v POST požadavcích a není vypínán politikami prohlížeče. Implementace: bílý seznam povolených originů, porovnání s aktuální hodnotou hlavičky. Metoda je účinná, ale složitá u mobilních aplikací, kde hlavičky Origin mohou chybět nebo být padělány.

// Příklad ověření CSRF tokenu v Spring Boot
@Configuration
@EnableWebSecurity
class SecurityConfig {
    @Bean
    fun securityFilterChain(
        @Autowired http: HttpSecurity
    ): SecurityFilterChain {
        return http
            .csrf { it.csrfTokenRepository(
                CookieCsrfTokenRepository.withHttpOnlyFalse()
            ) }
            .sessionManagement {
                it.sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED)
            }
            .build()
    }
}

Double Submit Cookie

Metoda, která nevyžaduje ukládání tokenu na serveru: server nastaví cookie s náhodnou hodnotou, klient přečte hodnotu z cookie a pošle ji zpět v hlavičce nebo těle požadavku. Server porovná obě hodnoty. Pokud útočník nemůže číst cookie (Same-origin policy), nebude moci padělat token. Metoda je jednodušší na implementaci než synchronizátor, ale vyžaduje HTTPS k ochraně cookie před odposlechem.

• CSRF tokeny — zlatý standard: spolehlivé, časem prověřené, podporované všemi frameworky
• SameSite=Lax — minimální ochrana pro webové aplikace: zdarma, automatická, nevyžaduje kód
• Kontrola Origin — další úroveň: blokuje útoky před kontrolou tokenu
• Double Submit — pro REST API bez serverových relací: účinné na HTTPS
• Vlastní hlavičky — X-Requested-With: XMLHttpRequest blokuje jednoduché CSRF formuláře

Rozdíl mezi CSRF a XSS

CSRF a XSS jsou různé typy útoků, které jsou často zaměňovány. CSRF zneužívá důvěru serveru v prohlížeč uživatele: server provede příkaz útočníka, protože požadavek přichází s platnými cookies. XSS zneužívá důvěru prohlížeče v obsah serveru: prohlížeč provede skript, který útočník injektoval do stránky. CSRF nevyžaduje injektáž kódu na cílovém webu — stačí odeslat požadavek z jiné domény. XSS naproti tomu vyžaduje nalezení způsobu, jak injektovat vlastní JavaScript do HTML kódu stránky. Kromě toho XSS může obejít CSRF ochranu: injektovaný skript přečte CSRF token ze stránky a pošle jej spolu s požadavkem.

Pochopení rozdílu mezi CSRF a XSS je kritické pro budování víceúrovňové ochrany. CSRF tokeny nechraní před XSS a CSP (Content Security Policy) nechraní před CSRF. Pouze kombinace metod zajišťuje bezpečnost aplikace proti oběma typům útoků. V mobilních aplikacích s WebView se rizika zdvojnásobují, proto se vývojářům doporučuje používat alespoň CSRF tokeny pro API požadavky a Content Security Policy pro webový obsah.