Cesko.wiki Cross-site request forgery
Author
Albert FloresCross-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 [url= metodu [[GET][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. +more 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[/url]]) 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. +more „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. +more 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 [url= [[autentizace[/url][Hypertext Transfer Protocol|HTTP]] metodu POST. (To útok CSRF znesnadňuje, ale ještě zcela nevylučuje. +more) * 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/url=HTTPS]nebo[/url]], 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. ).
Externí odkazy
http://php. vrana. +morecz/cross-site-request-forgery. php * http://www. cgisecurity. com/csrf-faq. html * [url=http://www. soom. cz/index. php. name=articles/show&aid=484&title=Cross-Site-Request-Forgery](SOOM. cz) Obsáhlý článek věnovaný útokům typu CSRF[/url] * [url=http://www. soom. cz/index. php. name=articles/show&aid=545&title=Referer-jako-ochrana-proti-CSRF](SOOM. cz) Proč nepoužívat hlavičku referer jako obranu před CSRF[/url].