https://wiki.knihovna.cz/index.php?action=history&feed=atom&title=CSRFCSRF - Historie editací2026-05-15T22:49:00ZHistorie editací této stránkyMediaWiki 1.35.0https://wiki.knihovna.cz/index.php?title=CSRF&diff=2950&oldid=prevMichal Klajban: 21 revizí: IMPORT C: import stránek z hlavního jmenného prostoru z KiskWiki (http://kisk.phil.muni.cz/)2012-02-06T11:03:41Z<p>21 revizí: IMPORT C: import stránek z hlavního jmenného prostoru z KiskWiki (http://kisk.phil.muni.cz/)</p>
<p><b>Nová stránka</b></p><div>'''Autor:''' Jaroslav Kvasnica<br />
<br />
'''Klíčová slova:''' informační bezpečnost, webové útoky, hacker, hacking<br />
<br />
'''Synonyma:''' Session Riding, Confused Deputy, XSRF<br />
<br />
'''Související pojmy:'''<br />
<br />
<blockquote><br />
''nadřazené'' - XSS, Clickjacking, HTTP, cookie, JavaScript, URL</blockquote><br />
<blockquote><br />
''podřazené'' - GET, POST, autorizační token, HTTP Referer</blockquote><br />
<br />
<br />
<br />
==Charakteristiky==<br />
<br />
'''Cross-site request forgery''' ('''CSRF''') je metoda webového útoku, která ''„spočívá v tom, že uživatele přimějeme navštívit stránku napadané aplikace, která provádí nějakou akci, aniž by o tom uživatel věděl“''.<ref name="vrana">VRÁNA, Jakub. PHP triky : Weblog o elegantním programování v PHP pro mírně pokročilé [online]. 24.4.2006 [cit. 2011-05-09]. Cross-Site Request Forgery. Dostupné z WWW: <http://php.vrana.cz/cross-site-request-forgery.php>.</ref> Cílem útočníka je donutit uživatele provést bez jeho vědomí akci v nějaké webové službě. Podmínkou pro úspěšné provedení útoku je útočníkova znalost napadené aplikace a vstup uživatele na útočníkovu infikovanou stránku nebo kliknutí na infikovaný odkaz.<br />
<br />
''„CSRF útok vždy představuje zvláštní internetový odkaz, který se útočník snaží podstrčit své oběti (zpravidla nějakému návštěvníkovi webových stránek) a který mu v případě úspěchu umožní provést skrytou akci pod cizí identitou.“'' <ref>HOLČÁK, Radek. Autentizace uživatelů a krádež identity. Brno, 2009. 97 s. Diplomová práce. Masarykova univerzita, Fakulta informatiky. Vedoucí práce doc. RNDr. Václav Matyáš, M.Sc., Ph.D. Dostupné z WWW: <http://is.muni.cz/th/98688/fi_m/thesis.pdf?info>.</ref> Infikovaný odkaz v sobě má zakódovaný správně formulovaný požadavek, který vykoná útočníkem zamýšlenou akci ve webové aplikaci. <br />
<br />
==Odesílání požadavku==<br />
Odeslání požadavku do služby je možné dosáhnout dvěmi způsoby. Pomocí metody [[GET]] a [[POST]].<br />
<br />
Metoda [[GET]] představuje odeslání požadavku přímo v [[URL|URL]] proměnné. Může vypadat například takto:<ref name="pejsa">PEJŠA, Jan. Zdroják (zdrojak.root.cz) : tvorba webových stránek a aplik [online]. 24. 11. 2008 [cit. 2011-05-09]. Co je Cross-Site Request Forgery a jak se mu bránit. Dostupné z WWW: <http://zdrojak.root.cz/clanky/co-je-cross-site-request-forgery-a-jak-se-branit/>. ISSN 1803-5620.</ref><br />
<br />
<code><img src="http://[[URL]]//poslat?komu=nejakyEmail@server&predmet=test&obsah=textemailu"></code><br />
<br />
V tomto příkladě jde o infikovaný obrázek, resp. o cestu k umístění obrázku (reálně žádný obrázek neexistuje). V odkazu je ukrytý požadavek na odeslání falešného emailu. Z toho plyne, že jakmile uživatel přistoupí na stránku s tímto falešným obrázkem, tak se odešle bez jeho vědomí požadavek na webovou službu a ta odešle falešný email.<br />
<br />
Při metodě [[POST]] se požadavky odesílají skrytě mimo samotný odkaz. V tomto případě útočník využívá při tvorbě infikovaného odkazu [[JavaScript]]. Může se stát, že má uživatel vypnutý [[JavaScript]] ve svém prohlížeči – v takovém případě útok selže. Ale moderní prohlížeče mají JavaScript implicitně povolený.<br />
<br />
U některých požadavků webové aplikace vyžadují, aby byl uživatel přihlášený. S tím útočník počítá a využívá [[cookie|cookies]]. Počítá s tím, že uživatel je ke službě přihlášeny již z minulosti.<br />
<br />
==Obrana za strany serveru==<br />
Proti CSRF je možné chránit se několika způsoby, které jsou víceméně účinné. Některé zdroje uvádějí obranu pomocí [[HTTP]] hlavičky Referer. Jedná se o hlavičku, která obsahuje URL předchozí stránky. Teoreticky bychom mohli zkontrolovat odkud požadavek pochází. ''„HTTP referer jde ale falšovat a dokonce se nemusí vůbec odesílat (nebo se může ztratit někde cestou – třeba v proxy).“''<ref name="pejsa"/><br />
Účinnou obranou pro CSRF jsou tzv. autorizační tokeny nebo také podepsané formuláře. V principu se jedná o dočasnou proměnnou, která nabývá unikátní hodnoty a je přidělena konkrétnímu požadavku nebo formuláři. Server si dočasně hodnotu zapamatuje a pak porovnává tento token s tím, který je odesílán v požadavku do webové aplikace. <br />
<br />
==Obrana ze strany uživatele==<br />
Pokud není samotný server zabezpečený, uživatel má také několik možností, jak se chránit. Hlavní zásadou je chovat se obezřetně. <br />
*Odhlašovat se z aplikací po ukončení práce s nimi. <br />
*Při práci např. s internetovým bankovnictvím neotvírat žádná další okna nebo záložky ve stejném prohlížeči. <ref name="pejsa" /><br />
*Aplikace, u kterých si nejsme jisti bezpečností, otevírat v samotné instanci prohlížeče. <ref name="vrana" /><br />
*Na internetové aplikace, které obsahují citlivá data, používat různé prohlížeče. <ref name="OWASP">PETERFISH, Paul; SHERIDAN, Eric; WICHERS, Dave. OWASP : The Open Web Application Security Project [online]. 12.10. 2009, 3.3. 2011 [cit. 2011-05-09]. Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet. Dostupné z WWW: <https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet>.</ref><br />
*Nepovolit prohlížeč ukládat uživatelské jméno a heslo; nepovolit stránkám pamatovat si přihlašovací jméno. <ref name="OWASP" /><br />
<br />
==Použitá literatura==<br />
<references /></div>Michal Klajban