CSRF, tato zkratka se znovu a znovu objevuje v poznámkách k aktualizacím jádra WordPressu. Metoda, která za ní stojí, je již stará známá a využívá obvykle hojné soubory cookie prohlížeče. Naštěstí se však před Cross Site Request Forgery můžete chránit poměrně snadno. Potřebujete jen trochu času a pozornosti.
Jistě používáte řadu služeb, které nabízejí možnost zůstat přihlášeni i po opuštění webové stránky. Pokud pak webovou stránku navštívíte znovu, nemusíte znovu zadávat přihlašovací údaje, ale jste přihlášeni přímo. To je samozřejmě skvělé, protože - stejně jako správa hesel nebo tzv. jednotné přihlašování - vám to ušetří vyplňování formulářů.
Na pozadí se děje následující: když se poprvé přihlásíte na webové stránky, webové stránky umístí do vašeho prohlížeče soubor cookie. Jedná se o malý textový soubor, ve kterém mohou být uloženy určité informace. V případě, že zůstáváte přihlášeni, jedná se o náhodně vygenerovaný řetězec.
Při příští návštěvě webové stránky server tento řetězec zkontroluje, a pokud najde odpovídající protějšek, automaticky vás přihlásí. To je také důvod, proč jste po vyprázdnění mezipaměti prohlížeče všude odhlášeni. Během tohoto procesu jsou totiž smazány i všechny soubory cookie.
Útoky CSRF jsou v jádru zneužitím důvěry.
Jak vidíte, při odpovídajícím útoku je služba, která soubory cookie čte, oklamána. Jak přesně k tomu dochází, vysvětlím níže na dvou příkladech.
Nebezpečí této manipulace spočívá například v tom, že někdo provede změny na vašem profilu na Facebooku vaším jménem. Na phishingu však často závisí i cross site request forgery. I zde se stává důležitou důvěra - například vaše důvěra v odesílatele e-mailů.
Jak je WordPress ohrožen?
Pravděpodobně jste neslyšeli termín Cross Site Request Forgery tak často jako. útoky hrubou silou nebo cross site scripting. Má to svůj důvod: nezisková organizace OWASP (Open Web Application Security Project) pravidelně zveřejňuje seznam deseti nejkritičtějších zranitelností webových aplikací. V průběhu let se CSRF jako bezpečnostní riziko propadalo stále níže a nyní z první desítky zmizelo.
Částečně je to pravděpodobně proto, že útoky CSRF jsou téměř stejně staré jako samotný internet. Profesionální vývojáři jsou nyní v zabezpečení svého kódu proti nim zkušení. Bezpečnostní rizika jsou tedy poměrně snadno a rychle odstranitelná.
WordPress je také ve střehu. Na adrese Mai byla například zveřejněna bezpečnostní aktualizace 4.7.5, která opravuje šest zranitelností, jež mohli hackeři využít k útoku prostřednictvím cross-site scripting nebo cross-site request forgery. Cross site scripting je však často považován za mnohem nebezpečnější.
Problém Cross Site Request Forgery se navíc týká spíše zásuvných modulů a aplikací než webdesignu, agentur a malých a středních podniků. Je to proto, že ochrana proti CSRF je také otázkou programování. CSRF se může stát relevantní například v případě nákupů v zásuvném modulu.
Ale jak to všechno funguje?
Anatomie podvržení požadavku Cross Site Request Forgery
Základní myšlenka útoku CSRF je poměrně jednoduchá a obvykle probíhá ve dvou krocích:
- Oběť je oklamána a je nucena načíst zmanipulovanou webovou stránku nebo kliknout na odkaz, například tak, že se zdá, že zpráva pochází od důvěryhodné osoby. Nebo je využita lidská zvědavost. Jinými slovy, phishing hraje v tomto typu útoku důležitou roli.
- Při načítání nebo kliknutí na zmanipulované odkazy nebo webové stránky provede prohlížeč oběti požadavek HTTP, aniž by si toho oběť všimla.
Dva relativně jednoduché příklady ilustrují, jak takový útok funguje.
Předpokládejme, že Justus chce převést 100 eur Bobovi prostřednictvím webové stránky www.bank.de a Skinny čeká, až provede útok CSRF. Skinny může pro svůj útok použít metodu GET nebo POST.
Mimochodem, následující příklady pocházejí z následujících zdrojů:
- "Cross Site Request Forgery (CSRF)" - přehledový článek OWASP
- "Prevence útoků CSRF ve WordPressu pomocí Nonces" - qnimate.com
Padělání požadavku Cross Site Request Forgery pomocí metody GET
Metoda GET se používá k vyžádání prostředku ze serveru, například souboru HTML. Potřebné parametry pro volání se jednoduše přidají do adresy URL. A jak už víme z injekcí SQL: URL lze poměrně snadno manipulovat.
Justus se přihlásí na www.bank.de a zadá všechny potřebné údaje. Na server by se přenesl následující (zcela fiktivní) vstup:
GET http://bank.de/transfer.do?acct=BOB&betrag=100 HTTP/1.1Skinny nyní vytvoří adresu URL, která místo toho převede 100 000 EUR na jeho vlastní účet. Vypadá to takto:
http://bank.de/transfer.do?acct=SKINNY&betrag=100000Justus samozřejmě musí provést akci skrytou za falešným odkazem. Proto Skinny pošle Justusovi e-mail s falešným odkazem. Kód HTML může vypadat například takto:
<a href="http://bank.de/transfer.do?acct=SKINNY&betrag=100000">Wer dieses Rätsel nicht lösen kann, ist kein echter Detektiv!</a>Nebo mu pošle e-mail s "neviditelným" (protože 0 na 0 pixelů) obrázkem. Při pokusu o načtení obrázku prohlížeč přistoupí na adresu URL, aniž by si toho Justus všiml:
<img src="http://bank.de/transfer.do?acct=SKINNY&betrag=100000" width="0" height="0" border="0">Když Justus vyvolá odkaz - ať už vědomě, nebo nevědomě -, parametry se předají serveru, spustí se převod a z jeho účtu zmizí 100 000 eur.
Justus samozřejmě musí na odkaz kliknout, když je přihlášený. Ale pokud je bohužel v jeho prohlížeči přihlašovací cookie od jeho banky, útok funguje, i když zrovna nemá otevřenou webovou stránku.
Právě proto je Cross Site Request Forgery tak zákeřný: Justus pravděpodobně ani neví, že soubor cookie existuje.
Podvodné vyžádání přes web pomocí metody POST
Metodu GET lze použít v odkazech, a proto je její šíření obzvláště snadné. Poskytovatelé však nyní mohou zajistit, aby požadavky GET zásadně nedostávaly povolení k zápisu.
Zůstává metoda POST: Zde se data přenášejí na server, aby je mohl dále zpracovat. Data nejsou součástí adresy URL, ale jsou připojena k hlavičce.
Může to znít trochu těžkopádně, ale určitě znáte případ použití, protože formuláře takto fungují.
Pro našeho útočníka Skinnyho to znamená, že musí vynaložit více úsilí, ale přesto se může dostat k brance.
Stejný scénář: Justus chce převést peníze Bobovi. Vyplní tedy následující formulář na adrese www.bank.de:
<form method="POST" action="geld_ueberweisen.php">
<input type="text" name="von">
<input type="text" name="an">
<input type="text" name="betrag_in_euro">
<input type="submit">
</form>Tím se odešle příkaz geld_ueberweisen.php, který vypadá takto:
if(isset($_FORM["von"]) && isset($_FORM["an"]) &&isset($_FORM["menge_in_euro"]) && isset($_CMOKIE["user_eingeloggt"]))
{
transMoney("von", "an", "betrag");
echo "Überweisung erfolgreich!";
}Jak vidíte, kód nejprve pomocí souboru cookie zkontroluje, zda je Justus přihlášen. Teprve poté se provede přenos.
Skinny nyní například na zmanipulované webové stránky vkládá neviditelný formulář:
<form method="POST" action="http://www.bank.de/geld_ueberweisen.php">
<input type="text" name="von" value="Justus" style="display: hidden">
<input type="text" name="an" value="Skinny" style="display: hidden">
<input type="text" name="betrag_in_euro" value="100000" style="display: hidden">
<input type="submit" value="Wer dieses Rätsel nicht lösen kann, ist kein echter Detektiv!">
</form>Odkaz na tuto zmanipulovanou webovou stránku pošle Justusovi. Ten se cítí být vyzván, klikne na tlačítko, aby se podíval na hádanku - a nevědomky spustí funkci geld_ueberweisen.php. Protože ta v jeho prohlížeči najde odpovídající soubor cookie, převede se 100 000 € opět na účet Skinnyho.
Útok objížďkami
Proto se mu říká cross-site request forgery: příkaz je obvykle odeslán z jiné webové stránky. Aby mohl zaútočit na web A, uloží škodlivý kód na web B. Oběť je sem pak nalákána, aby její prohlížeč kód spustil. Poté sem naláká nic netušící oběť, aby její prohlížeč spustil kód.
"*" povinný údaj
Jak se chránit před útoky CSRF
Dobrá zpráva: Cross Site Request Forgery je známo již dlouho. Riziko je známé a vývojáři pracují speciálně na jeho odstranění.
Špatnou zprávou je, že po technické stránce se proti němu vlastně nemůžete chránit. Jádro WordPressu je nyní poměrně dobře chráněno, a jak je vidět z průběžných aktualizací, neustále se na něm pracuje. Stejně jako u jiných typů útoků pochází většina zranitelností z pluginů. Musíte tedy věřit, že vývojáři rozšíření, která používáte, odvádějí dobrou práci.
Konkrétně to znamená:
- Neinstalujte příliš mnoho zásuvných modulů a instalujte pouze ty, které skutečně potřebujete.
- Buďte opatrní u dlouho neaktualizovaných modulů plug-in. Mohou se zde skrývat neopravené bezpečnostní mezery.
- Předem si zjistěte informace o instalovaných pluginech, například o jejich kompatibilitě s jinými pluginy nebo o verzi WordPressu, kterou používáte (aby bylo možné plugin také aktualizovat).
- Pravidelně aktualizujte své pluginy a jádro WordPressu. Průběžné aktualizace totiž slouží právě k odstranění takových bezpečnostních mezer.
- Buďte kritičtí k phishingu.
- Pokud si nejste jisti, podívejte se na plugin v repozitáři WP. Jaká jsou hodnocení, jaké byly největší problémy v minulosti a zda plugin případně neuzavřel nějakou významnou bezpečnostní díru?
Závěr: CSRF je starý klobouk
Podvodné vyžádání mezi stránkami se objevuje již od počátku digitálního věku. Počet případů je navíc ve srovnání s útoky hrubou silou velmi malý.
To potvrzuje i hodnocení OWASP: zde se předpokládá, že útok je poměrně rozšířený, snadno odhalitelný a závažný jen ve velmi specifických případech.
Přesto je dobré vědět, jak útoky fungují. Protože útoky často fungují jen díky lidské chybě. Znovu a znovu uživatelé otevírají e-maily ze zvědavosti nebo klikají na odkazy, které by neotevřeli lépe.
Nejlepším způsobem, jak se chránit před cross-site request forgery, je provést průzkum a použít trochu zdravého rozumu.
