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 neočekávaného resp. 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 zobrazil (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 na adresu (popř. kombinaci adresy a proměnných) do zmíněné internetové aplikace, který způsobí změnu určitých záznamů či objektů, které 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šimnul), nebo (pro metodu POST) sestavením 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 aplikace není schopna odlišit, z jakého podnětu požadavek přišel (zda-li z její vlastní administrační stránky nebo právě z CSRF útoku) – tento útok tedy patří do skupiny tzv. „problému zmateného zástupce“ (en:Confused deputy problem), 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 a mnohdy zůstanou dlouho 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 zobrazí pro útočníka zajímavé nebo potenciálně zneužitelné informace. Přístupové údaje k jiným účtům mezi ně ale většinou nepatří a konkrétně hesla většina aplikací z pochopitelných důvodů zobrazuje nepředvyplněná a při možnosti jej změnit navíc s podmínkou zadání starého hesla.

 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é (tj. pro každý vygenerovaný formulář) jiné. 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 se zřejmě 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ů) autorizační token není schopen 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ích, s kterými je možno ji 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, stratifikace uživatelských práv, atd.).