Cross-Site Request Forgery (CSRF) útoky na WordPress patří mezi nejstarší útoky vůbec.

Cookies jako nebezpečí: Padělání žádostí mezi weby

CSRF, tato zkratka se znovu a znovu objevuje v aktualizacích zabezpečení a údržby jádra WordPress. Metoda za ním je nyní starý klobouk a využívá hojné soubory cookie uživatele internetu. Naštěstí se můžete chránit před paděláním požadavků mezi weby poměrně snadno. Vše, co potřebujete, je trochu času a pozornosti.

Určitě také využijete celou řadu služeb, kde je možnost zůstat přihlášeni i poté, co opustíte web. Pokud pak navštívíte stránky znovu, nemusíte znovu zadávat své přihlašovací údaje, ale budete přihlášeni přímo. Pro uživatele je to samozřejmě skvělé, protože to šetří - stejně jako správa hesel nebo takzvané jednotné přihlašování - nepříjemné vyplňování formulářů.

Na pozadí funguje následující: Když se poprvé přihlásíte na web, web uloží do vašeho prohlížeče soubor cookie. Jedná se o malý textový soubor, ve kterém lze ukládat určité informace. V případě, že zůstanete přihlášeni, jedná se o náhodně vygenerovaný řetězec znaků.

Při vaší další návštěvě webových stránek server zkontroluje tento řetězec znaků a pokud najde odpovídající protějšek, automaticky vás přihlásí. Mimochodem, to je také důvod, proč se při vyprázdnění mezipaměti prohlížeče všude odhlásíte. Protože během tohoto procesu jsou také smazány všechny soubory cookie.

Útok CSRF je v podstatě zneužitím důvěry

Již jste si všimli: Při odpovídajícím útoku útočník oklame službu, která čte soubory cookie. Jak přesně se to stane, vysvětlím níže dvěma příklady.

Nebezpečí této manipulace spočívá v tom, že třetí strana, tj. útočník, provede změny na vašem profilu na Facebooku například vaším jménem. Padělání požadavků mezi weby je však často také závislé na phishingu. I zde se důvěra stává relevantní – konkrétně vaše důvěra například v odesílatele e-mailů.

Útokům Cross Site Request Forgery (CSRF) na WordPress lze zabránit zdravým rozumem.

Jak je WordPress ohrožen?

Pravděpodobně jste neslyšeli termín padělání požadavků mezi weby tak často jako útoky hrubou silou nebo skriptování mezi weby. 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í ve webových aplikacích. Na předběžném seznamu pro rok 2017 zaujímá CSRF 8. místo z 10. V letech 2007 a 2010 útok přistál na 5. místě, v roce 2013 klesl na 8. místo.

To je pravděpodobně částečně způsobeno skutečností, že útoky CSRF jsou téměř stejně staré jako samotný internet. Profesionální vývojáři jsou nyní zběhlí v zabezpečení svého kódu proti němu. Bezpečnostní rizika jsou proto řešena poměrně snadno a rychle.

WordPress je také ve vaší stráži. Například v květnu byla vydána aktualizace zabezpečení 4.7.5, která opravila šest zranitelností, které hackeři mohli použít k útoku prostřednictvím skriptování mezi weby nebo padělání požadavků mezi weby. Skriptování mezi weby je však často považováno za mnohem nebezpečnější.

Kromě toho je otázka padělání žádostí mezi weby relevantnější pro vývojáře pluginů a aplikací než pro webové designéry, agentury a malé a střední podniky. Protože ochrana proti CSRF je také otázkou programování. CSRF by se mohl stát relevantním například pro nákupy v pluginu.

Ale jak to všechno funguje?

Anatomie cross-site request forgery

Základní myšlenka CSRF útoku je poměrně jednoduchá a obvykle se děje ve dvou krocích:

  1. Hacker přiměje oběť, aby načetla manipulovanou stránku nebo klikla na odkaz, například tím, že se vydává za důvěryhodnou osobu nebo zneužívá lidskou zvědavost. Jinými slovy, phishing hraje v tomto typu útoku důležitou roli.
  2. Při načítání nebo kliknutí na manipulované odkazy nebo 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 Boba www.bank.de 100 € přes web a Skinny čeká na provedení útoku CSRF. Skinny nyní může používat např. Použijte metody GET nebo POST.

Mimochodem, následující příklady pocházejí z následujících zdrojů:

Cross-Site Request Forgery na metodě GET

Metoda GET se používá k vyžádání prostředku ze serveru, jako je například soubor HTML. Požadované parametry pro volání jsou jednoduše připojeny k adrese URL. A jak již víme z injektáží SQL : Adresa URL je relativně snadno manipulovatelná.

Justus se přihlásí do www.bank.de a zadá všechna potřebná data. Následující (zcela fiktivní) vstup by byl přenesen na server:

ZÍSKAT http://bank.de/transfer.do?acct=BOB&betrag=100 HTTP/1.1

Skinny nyní vytváří adresu URL, která místo toho převádí 100 000 EUR na jeho vlastní účet. Vypadá to takto:

http://bank.de/transfer.do?acct=SKINNY&betrag=100000

Justus musí samozřejmě také provést akci skrytou za falešným odkazem. To je důvod, proč Skinny pošle Justusovi e-mail s falešným odkazem. Kód HTML může vypadat například takto.B:

<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 obsahující "neviditelný" (protože 0 x 0 pixelů) obrázek. Při pokusu o načtení obrázku prohlížeč přistupuje k adrese URL, aniž by si To Justus uvědomil:

<img src="http://bank.de/transfer.do?acct=SKINNY&betrag=100000" width="0" height="0" border="0">

Když Justus vyvolá odkaz – vědomě nebo nevědomě – parametry jsou předány serveru, převod je spuštěn a 100 000 € zmizí z jeho účtu.

Justus samozřejmě musí kliknout na odkaz, když je přihlášen. Pokud je však bohužel v jeho prohlížeči přihlašovací soubor cookie z jeho banky, útok bude fungovat, i když stránku právě neotevřel.

To je přesně to, co dělá Cross-Site Request Forgery tak nevyzpytatelným: Poškozená strana si ani nemusí být vědoma toho, že soubor cookie existuje.

Padělání požadavků mezi weby v metodě POST

Metoda GET může být použita v odkazech, a proto je obzvláště snadná k distribuci. Samozřejmě, že to hraje do rukou útočníka, pokud jde o distribuci. Nyní však mohou poskytovatelé zajistit, aby požadavky GET v zásadě neobdržely oprávnění k zápisu.

Zbývá metoda POST: Data jsou přenášena na server, aby je mohl dále zpracovávat. Data však nejsou součástí adresy URL, ale jsou připojena k záhlaví.

Může to znít trochu objemně, ale určitě znáte případ použití. Protože formuláře fungují tímto způsobem.

Pro našeho útočníka Skinnyho to znamená, že musí vynaložit větší úsilí, ale stále se tam může dostat.

Stejný scénář: Justus chce převést peníze na Boba. Na w ww.bank.de tedy vyplní následující formulář:

<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 použije soubor cookie ke kontrole, zda je Justus přihlášen. Pouze v případě, že tomu tak je, bude převod proveden.

Skinny nyní ukládá neviditelný formulář na manipulovaný web, e.B.

<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>

Pošle odkaz na tuto zmanipulovanou webovou stránku Justusovi. Cítí se vyzván, klikne na tlačítko, aby viděl hádanku; a již nevědomky vykonává funkci geld_ueberweisen.php. Vzhledem k tomu, že ve svém prohlížeči najde odpovídající soubor cookie, bude 100 000 € znovu převedeno na Skinnyho.

Útok objížďkami

To je důvod, proč název Cross-Site Request Forgery: Hacker obvykle odešle příkaz z jiné stránky. Aby mohl zaútočit na stránku A, uloží škodlivý kód na stránku B. Pak sem naláká nic netušícího uživatele, aby jeho prohlížeč spustil kód.

Jak nebezpečné jsou útoky Cross Site Request Forgery (CSRF) na WordPress?

Jak se chránit před útoky CSRF

Dobrá zpráva: Cross-Site Request Forgery je znám již věky. Vývojáři znají riziko a pracují konkrétně na jeho eliminaci.

Špatná zpráva: Nemůžete se proti tomu opravdu chránit po technické stránce. Jádro WordPress je nyní poměrně dobře chráněno a jak můžete vidět z probíhajících aktualizací, neustále se na něm pracuje. Stejně jako u jiných typů útoků, většina zranitelností přichází s pluginy. Takže musíte věřit, že vývojáři rozšíření, která používáte, dělají dobrou práci.

Konkrétně to znamená:

  • Neinstalujte příliš mnoho pluginů a pouze pluginy, které opravdu potřebujete
  • Dávejte si pozor na pluginy, které vývojáři již nějakou dobu neaktualizovali. To může skrýt neopevné bezpečnostní mezery.
  • Informujte se předem o pluginech, které instalujete, e.B. o jejich kompatibilitě s jinými pluginy nebo verzí WordPress, kterou používáte (aby bylo možné plugin také aktualizovat).
  • Pravidelně aktualizujte své pluginy a jádro WP. Protože průběžné aktualizace jsou přesně tam, aby uzavřely takové bezpečnostní mezery.
  • Jste kritičtí k phishingu
  • Pokud si nejste jisti: Podívejte se zblízka na plugin v úložišti WP. Jaká jsou hodnocení, jaké byly největší problémy v minulosti a plugin možná neuzavřel prominentní bezpečnostní chybu?

Závěr: CSRF je starý klobouk

Cross-Site Request Forgery existuje od počátku digitálního věku. Kromě toho je počet případů extrémně malý ve srovnání například s útoky hrubou silou .

To potvrzuje i hodnocení OWASP: Zde se předpokládá, že útok je poměrně málo rozšířený, snadno detekovatelný a závažný pouze 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.

Ať už jako uživatel nebo uživatel: Nejlepší způsob, jak se chránit před paděláním požadavků mezi weby, je výzkum a zdravý rozum.

Líbil se vám tento článek?

Svou recenzí nám pomůžete zlepšit náš obsah.

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna.