Cross-site request forgery
Cross-site Request Forgery (CSRF nebo také XSRF) je jedna z metod útoku do internetových aplikací (typicky implementovaných skriptovacími jazyky nebo CGI) pracující na bázi nezamýšleného požadavku pro vykonání určité akce v této aplikaci, který ovšem pochází z nelegitimního zdroje. Většinou se nejedná o útok směřující k získání přístupu do aplikace (i když i pro to může být zneužit); spíše využívá (zneužívá) akce uživatelů, kteří jsou k ní již v okamžiku útoku přihlášeni.
Příklad
Existuje nějaká netriviální internetová aplikace (typu wiki, blog, diskuzní fórum, e-shop, redakční systém, …), která má svou administrační část, přístupnou pouze pro administrátory, a u které útočník zná (nebo dokáže odhadnout) URL adresy (popřípadě i posílané proměnné) pro spuštění akcí určených na změnu (editaci obsahu, smazání, …) jejích objektů (příspěvků na blogu či fóru, článků v redakčním systému či wiki, apod.).
Útočník současně zná (je v kontaktu, nebo dokáže oslovit a přesvědčit) jiného uživatele, který se do této aplikace již přihlásil a operuje v ní s administrátorskými právy. Útočník poté (většinou s využitím tzv. sociálního inženýrství) přiměje tohoto administrátora, aby načetl (jím předem připravenou) maligní internetovou stránku, která provede samotný CSRF útok.
Ten spočívá v tom, že součástí této maligní stránky je vyslání požadavku do exploitované internetové aplikace, jenž způsobí změnu určitých záznamů či objektů, které aplikace spravuje. Tento požadavek (HTTP Request) může být realizován (pro HTTP metodu GET) přímo v HTML, pomocí značky, u které se specifikuje zdroj (obrázek, rám stránky, …, navíc často pomocí stylů nebo atributů skryté nebo minimalizované, aby si jich původce požadavku nevšiml); nebo (pro metodu POST) sestavením a provedení požadavku ve skriptovacím jazyce při zpracování stránky.
Útok je úspěšný, pokud v okamžiku požadavku na tuto stránku je uživatel, který maligní stránku spustil, do aplikace platně přihlášen a tato aplikace není proti tomuto typu útoku zabezpečena. Skrytý požadavek na editaci nebo smazání objektů v inkriminované aplikaci se tak vykoná, protože nezabezpečená aplikace nedokáže rozlišit, z jakého podnětu požadavek přišel (zdali z její vlastní administrační stránky nebo z maligní stránky provádějící CSRF útok) – tento útok tedy patří do skupiny tzv. „problému zmateného zástupce“, která je charakteristická tím, že strůjcem maligní akce je nikoli útočník, ale legitimně přihlášený uživatel. Změny se projeví, aniž by to tušil; mohou dokonce zůstat nezjištěny.
Útočník nemusí znát, který záznam chce takto nechat nic netušícím administrátorem smazat nebo změnit, přesto v nechráněné aplikaci je schopen způsobit často neopravitelné škody. Méně často se může pokusit nechat spustit požadavek, který žádný objekt nemění, a místo toho vypíše pro útočníka zajímavé nebo potenciálně zneužitelné informace. CSRF útok u typické internetové aplikace typicky nedokáže získat přístupy k uživatelským účtům, na druhé straně dokáže nadělat mnohdy nezvratitelné škody ve formě důležitých přepsaných dat.
Opatření proti CSRF
- V administrační části internetových aplikací, pro akce, které mažou určité záznamy nebo je jiným způsobem mění, se doporučuje zásadně používat HTTP metodu POST. (To útok CSRF znesnadňuje, ale ještě zcela nevylučuje.)
- Používat autorizační token – tedy náhodně vygenerovaný řetězec pro tuto akci, platící jen pro aktuálního uživatele, ideálně pokaždé jiný (pro každý formulář, který nabízí k vyplnění). Typicky skript, starající se o administrační část aplikace, si před zobrazením formuláře vygeneruje tento autorizační token, který si jednak zapamatuje (uloží do session, databáze, …) a současně do onoho formuláře vloží (jako skryté vstupní pole). Při zpracování odeslaných dat pak tuto proměnnou porovnává s předtím uloženou hodnotou. V případě shody může požadavek zpracovat, v případě neshody lze předpokládat, že se jedná o pokus o Cross-Site Request Forgery. Autorizační token by neměl být od ničeho odvozený, zcela stačí v podobě (dostatečně velkého) náhodného čísla. Zatímco administrátor jej má v každém nabídnutém formuláři aplikace automaticky předvyplněný, útočník (nezávisle na počtu zaslaných podvrhnutých požadavků) nemá jak autorizační token uhodnout.
- Implementace autorizačním tokenem je sama o sobě považována za dostatečné opatření proti CSRF útokům. Nicméně, je více než vhodné používat ji v rámci ostatních bezpečnostních opatření, s kterými je doporučeno je kombinovat (zabezpečení webového serveru, nastavení limitů a přístupových práv, použití SSL/HTTPS nebo HTTP autentizace, zásady pro ukládání citlivých údajů a hesel (např. tzv. password salting, vyžadování starého hesla při jeho změně), ošetřování vstupů od uživatele (mj. escapování), stratifikace uživatelských práv, atd.).