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

Tobias Schüring Naposledy aktualizováno 21. ledna 2020
7 min.
Padělání požadavků mezi weby (CSRF) útočí v WordPress patří k nejstarším útokům vůbec.

CSRF, tato zkratka se znovu a znovu objevuje v aktualizacích zabezpečení a údržby WordPress -Jádro. Metoda, která za ním stojí, je nyní starým kloboukem a využívá hojné soubory cookie uživatele internetu. Naštěstí je však poměrně snadné se chránit před padělky žádostí mezi weby. Vše, co potřebujete, je trochu času a pozornosti.

Určitě využijete celou řadu služeb, kde je možnost zůstat přihlášeni i po odchodu z webu. Pokud pak web znovu navštívíte, nebudete muset znovu zadávat své přihlašovací údaje, ale budete přihlášeni přímo. To je samozřejmě skvělé pro uživatele, protože šetří nepříjemné vyplňování formulářů, stejně jako správa hesel nebo tzv. jednotné přihlášení.

Na pozadí se stane následující: Když se poprvé přihlásíte na stránku, webová stránka uloží soubor cookie ve vašem prohlížeči. Jedná se o malý textový soubor, který může ukládat konkrétní informace. V případě přihlášení se jedná o náhodně generovaný znakový řetězec.

Při vaší další návštěvě webu server zkontroluje tento znakový řetězec a pokud najde příslušný protějšek, automaticky se přihlásí. Mimochodem, to je také důvod, proč budete odhlášeni všude, když vyprázdníte mezipaměť prohlížeče. Tento proces také odstraní všechny soubory cookie.

Útok CSRF je v jádru nedůvěryhodný

Již jste si všimli: V odpovídajícím útoku útočník obelstí službu, která čte soubory cookie něco. Vysvětlím přesně, jak se to děje ve dvou příkladech níže.

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

Útoky na padělání požadavků mezi weby (CSRF) na WordPress lze předcházet zdravým rozumem.

Jak zranitelná je WordPress ?

Pravděpodobně jste neslyšeli termín Padělání žádostí mezi weby tak často jako vy Brute Force Útoky nebo skriptování mezi weby. Existuje pro to důvod: Nezisková organizace OWASP (Open Web Application Security Project) pravidelně publikuje seznam deseti nejdůležitějších chyb zabezpečení ve webových aplikacích. Na prozatímním seznamu pro rok 2017 je CSRF na 8. místě z 10. místa v letech 2007 a 2010, útok se stále umístil 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í vyškoleni v zabezpečení svého kódu proti němu. Bezpečnostní rizika jsou proto snadno a rychle řešena.

Na WordPress jste také ve střehu. Například aktualizace zabezpečení 4.7.5 byla vydána v květnu, která vyčistila šest chyb zabezpečení, které mohly způsobit útok hackerů 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 má otázka padělání žádostí mezi weby tendenci být více Plugin - a vývojáři aplikací relevantnější než pro webové designéry, agentury a míchané podniky. Protože ochrana proti CSRF je také otázkou programování. Relevantní je, že csrf by mohl být například Plugin Nákupy.

Ale jak to všechno funguje teď?

Anatomie padělání žádostí mezi weby

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

  1. Hacker způsobí, že oběť načte ohroženou stránku nebo klikne na odkaz, například předstíráním, že je správcem nebo zneužívá lidskou zvědavost. Jinými slovy, phishing hraje důležitou roli v tomto typu útoku.
  2. Při načítání nebo kliknutí na zmanipulované odkazy nebo stránky provede prohlížeč oběti požadavek HTTP, aniž by si toho oběť všimne.

Dva relativně jednoduché příklady ilustrují, jak takový útok funguje.

Předpokládejme, že justus chce převést Boba přes stránku www.bank.de 100 € a Skinny je na návnadě, aby provedl útok CSRF. Skinny může být nyní například zodpovědný za svůj útok. Použijte metodu GET nebo POST.

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

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

Metoda GET požaduje prostředek ze serveru, například soubor HTML. Požadované parametry volání jsou jednoduše připojeny k adrese URL. A jak již víme z injekcí SQL, s URL je relativně snadné manipulovat.

Justus se přihlásí www.bank.de a zadá všechna požadovaná data. Na server by byl přenesen následující (zcela fiktivní) vstup:

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

Skinny nyní vytvoří adresu URL, která místo toho převede 100 000 EUR na svůj vlastní účet. Vypadá to takhle:

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

Samozřejmě, Justus musí také provést akci skrytou za falešným odkazem. Proto Skinny Justus posílá e-mail s falešným odkazem. Například .B HTML může vypadat takhle:

">Ktež ten, kdo nemůže vyřešit tuhle hádanku, není skutečný detektiv!

Nebo mu pošle e-mail obsahující obrázek "neviditelný" (protože 0 krát 0 pixelů). Při pokusu o načtení obrázku prohlížeč přistupuje k adrese URL, aniž by si toho Justus vůbec všimne:

Když Justus zavolá na linku vědomě nebo nevědomě, parametry jsou předány serveru, přenos se spustí 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 prohlížeči přihlašovací cookie z jeho banky, útok funguje, i když stránku neotevřel.

To je přesně to, co forgery žádostí mezi weby dělá tak záludně: oběť si nemusí ani uvědomit, že soubor cookie existuje.

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

Metodu GET lze použít v odkazech, a proto se obzvláště snadno šíří. To samozřejmě nahrává útočníkovi, pokud jde o distribuci. Nyní však mohou zprostředkovatelé zajistit, aby požadavky GET v zásadě neobdržely oprávnění k zápisu.

Stále existuje metoda POST: Data jsou předána serveru, aby je mohl dále zpracovávat. Data však nejsou součástí adresy URL, ale jsou připojena k záhlaví.

Zní to trochu objemně, ale určitě znáte případ použití. Protože formuláře takhle fungují.

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

Stejný scénář: Justus chce převést peníze na Boba. Takže vyplní následující formulář na www.bank.de:

<metoda formuláře=akce "POST" ="geld_ueberweisen.php"> vstupní typ      <  ="text" název ="od"> vstupní typ      <  ="text" název="a">      < vstupní typ="text" název="betrag_in_euro"> vstupní      <  typ="odeslat">  >

Tím se odešle příkaz geld_ueberweisen.php, který vypadá takhle:

if(isset($_FORM["von"]) && isset($_FORM["an"]) &&isset($_FORM["menge_in_euro"]) && isset($_CMOKIE["user_eingeloggt"]))

{

    transMoney("von", "an", "betrag");

    echo "Überweisung erfolgreich!";

}

Jak můžete vidět, kód zkontroluje soubor cookie, aby zjistil, zda je Justus přihlášen. Pouze pokud ano, převod bude proveden.

Skinny nyní uloží neviditelný formulář na zmanipulované webové stránky, e.B.

<metoda formuláře=akce "POST" ="http://www.bank.de/geld_ueberweisen.php">      <  vstupnítyp="text" název =hodnota "from" =styl"Justus" ="display: hidden">      < input type="text" name="an" hodnota="Skinny" style="display: hidden">      < input type="text" name="betrag_in_euro" value="100000" style="display: hidden        <      >"    není skutečnýdetektiv!" > formulář>

Pošle odkaz na tuto zmanipulovaný web 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 to najde odpovídající soubor cookie ve svém prohlížeči, 100 000 € bude znovu převedeno do Skinny.

Útok objížďkou

To je důvod, proč název Forgeryžádostí meziweby: Hacker obvykle odešle příkaz z jiné stránky. Za účelem útoku na stranu A se tak uloží na škodlivý kód stránky B. Pak sem naláká nic netušícího uživatele, aby jeho prohlížeč kód spouštěl.

Jak nebezpečné jsou útoky na žádost o mezi weby (CSRF) WordPress ?

Jak bojovat proti útokům CSRF

Dobrá zpráva: Padělání žádostí mezi weby je známo již věky. Vývojáři znají riziko a pracují speciálně na tom, aby se ho zbavili.

Špatná zpráva je, že se před tím z technického důvodů opravdu nemůžete chránit. Tá WordPress -Core je nyní relativně dobře chráněn, a jak můžete vidět z probíhajících aktualizací, neustále na tom pracujeme. Stejně jako u jiných typů útoků je většina zranitelných míst Plugins Proto. Takže musíte věřit, že vývojáři rozšíření, která používáte, odvádí dobrou práci.

Konkrétně to znamená:

  • Instalační program není příliš mnoho Plugins a pouze Plugins , které opravdu potřebujete
  • Pozor Plugins , které vývojáři již nějakou dobu neaktualizovali. To může skrýt nevyřešené chyby zabezpečení.
  • Informujte se předem o Plugins , které nainstalujete, .B o jejich kompatibilitě s jinými Plugins nebo WordPress verzi, kterou používáte (aby Plugin také aktualizace).
  • Aktualizujte Plugins a WP-Core pravidelně. Protože k uzavření těchto chyb zabezpečení existují průběžné aktualizace.
  • kritizujete phishing
  • Pokud si nejste jisti: Podívejte se na to Plugin v úložišti WP. Jak recenze selžou, jaké byly největší problémy v minulosti a má Plugin významná chyba zabezpečení nemusí být uzavřena?

Verdikt: CSRF je starý klobouk

Padělání žádostí mezi weby je již od počátku digitálního věku. Kromě toho se čísla případu porovnávala např. Brute Force Útoky extrémně malé.

To potvrzuje i hodnocení OWASP: předpokládá se, že útok je poměrně nízký, snadno zjistitelný a závažný pouze ve velmi specifických případech.

Nicméně je dobré vědět, jak útoky fungují. Protože útoky často fungují jen díky lidským chybám. Uživatelé znovu a znovu otevírají e-maily ze zvědavosti nebo kliknou na odkazy, které by raději neotevřeli.

Ať už jako uživatel nebo uživatel, nejlepší způsob, jak se chránit před padělky žádostí mezi weby, je to s výzkumem a zdravým rozumem.

Jako správce systému společnosti monitoruje Tobias naši infrastrukturu a najde veškeré body pro optimalizaci výkonu našich serverů. Vzhledem k jeho neúnavnému úsilí ho lze často nalézt na Slacku i v noci.

Podobné články

Komentáře k tomuto článku

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna. Povinná pole jsou označena *.