Cookies jako nebezpečí: Cross-Site Request Padělek

Tobias Schüring Aktualizováno Dne 21.ledna 2020
7 min.
Útoky na padělání napříč místy (CSRF) 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 za ním je nyní starý klobouk a využívá hojné cookies uživatele internetu. Naštěstí je však poměrně snadné se chránit před cross-site Request Forgery. Vše, co potřebujete, je trochu času a pozornosti.

Budete určitě používat celou řadu služeb, kde je možnost zůstat přihlášeni i poté, co opustíte stránky. 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, samozřejmě, je to skvělé, protože to - stejně jako správa hesel nebo tak-zvané. Jednotné přihlašování - šetří nepříjemné vyplňování formulářů.

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

Při 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č jste odhlášeni všude, když Mezipaměť prohlížeče leerst. Tento proces také odstraní všechny soubory cookie.

Útok CSRF je jádrem nedůvěry

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

Nebezpečí této manipulace spoje na tom, že třetí strana, tedy útočník, provede změny na vašem facebookovém profilu, například vaším jménem. Cross-Site Request Falgery je také často závislá na phishingu. I zde se důvěra stává relevantní – a toje vaše důvěra například v odesílatele e-mailů.

Útoky na padělání mezi webovými servery (CSRF) WordPress lze předejít zdravým rozumem.

Jak zranitelná je WordPress ?

Pravděpodobně jste neslyšeli termín Cross-Site Request Padělek tak často, jak jste Brute Force Útoky nebo Skriptování mezi weby. Existuje pro to důvod: Nezisková organizace OWASP (Open Web Application Security Project) pravidelně zveřejňuje seznam deseti nejdůležitějších chyb zabezpečení webových aplikací. Na předběžný seznam na rok 2017 csRF zařadil 8th z 10th 2007 a 2010 útok ještě přistál na 5.místě, V roce 2013 se vyšplhala na 8. Vypnuto.

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í jejich kód proti němu. Bezpečnostní rizika jsou proto snadno a rychle řešena.

Na WordPress jste také na stráži. 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 vyžádání napříč webovými stránkami. Často ale v té době Skriptování mezi weby mnohem nebezpečnější.

Kromě toho je otázka cross-site Request Padělek inklinuje být více Plugin - a vývojáři aplikací relevantnější než pro webové designéry, agentury a malé a střední podniky. Protože ochrana proti CSRF je také otázkou programování. Relevantní, CSRF by například mohlo být Plugin Nákupy.

Ale jak to všechno funguje teď?

Anatomie cross-site žádosti padělání

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 tím, že předstírá, že je správcenebo využí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 prohlížeč oběti provede 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, aby Bob překračoval stránku. www.bank.de 100 eur a Skinny sedí na návnadě, aby provedl útok CSRF. Skinny může být nyní například zodpovědný za jeho útok. Použijte metodu GET nebo POST.

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

Padělání žádostí na příčce webu při metodě GET

Metoda GET požaduje prostředek ze serveru, například soubor HTML. Požadované parametry pro volání jsou jednoduše připojeny k adrese URL. A jak jsme již viděli z Injekcí SQL Know: Adresa URL se poměrně snadno manipuluje.

Justus se přihlašuje do www.bank.de a zadá všechna požadovaná data. Následující (zcela fiktivní) vstup by být přeneseny na server:

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

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

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

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

"Pokud nemůžete vyřešit tuto hádanku, nejste skutečný detektiv!

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

Když Justus zavolá odkaz, vědomě nebo nevědomě, parametry jsou předány na server, přenos se spustí a 100.000 € zmizí z jeho účtu.

Samozřejmě, Justus musí kliknout na odkaz, zatímco je přihlášen. Nicméně, pokud bohužel je přihlašovací cookie z jeho banky v jeho prohlížeči útok funguje, i když stránku neotevřel.

To je přesně to, co Cross-Site Request Padělek dělá tak záludně: oběť nemusí být ani vědomi toho, že cookie existuje.

Padělání žádostí na příčce webu při metodě POST

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

Stále existuje metoda POST: Data jsou předána serveru, aby je mohla dále zpracovat. Data však není součástí adresy URL, ale je připojen k záhlaví.

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

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

Stejný scénář: Justus chce převést peníze na Boba. Tak se to zaplní Www.bank.de tento formulář:

<Formulář Metoda="PŘÍSPĚVEK" Akce="geld_ueberweisen.php">

    <Vstupní Typ="text" Jméno="od">

    <Vstupní Typ="text" Jméno="zapnuto">

    <Vstupní Typ="text" Jméno="betrag_in_euro">

    <Vstupní Typ="odeslat">

Formulář>

To pošle příkaz geld_ueberweisen.php, který vypadá takto:

Pokud(Sada isset("_FORM["od"]) && Sada isset("_FORM["zapnuto"]) &&Sada isset("_FORM["menge_in_euro"]) && Sada isset("_CMOKIE["user_eingeloggt"]))

{

    transMoney("od", "zapnuto", "částka");

    Echo "Transfer úspěšný!";

}

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í ukládá neviditelný formulář na kompromitované webové stránce, např.

<Formulář Metoda="PŘÍSPĚVEK" Akce="http://www.bank.de/geld_ueberweisen.php">

    <Vstupní Typ="text" Jméno="od" Hodnotu="Justus" Styl="zobrazení: skryté">

    <Vstupní Typ="text" Jméno="zapnuto" Hodnotu="Hubený" Styl="zobrazení: skryté">

    <Vstupní Typ="text" Jméno="betrag_in_euro" Hodnotu="100000" Styl="zobrazení: skryté">

    <Vstupní Typ="odeslat" Hodnotu="Pokud nemůžete vyřešit tuto hádanku, nejste skutečný detektiv!">

Formulář>

Posílá odkaz na tuto zmanipulovně stránku Justusovi. Cítí se vyzývavě, klikne na tlačítko, aby viděl hádanku; a už nevědomky vykonává funkci geld_ueberweisen.php. Vzhledem k tomu, že to najde odpovídající cookie ve svém prohlížeči, 100.000 € budou převedeny na Skinny znovu.

Útok přes objížďky

To je důvod, proč jméno Kříž-Site Request Forgery: Hacker obvykle odešle příkaz z jiné stránky. Aby bylo možné zaútočit na stránku A, tak se ukládá na stránku B škodlivý kód. Pak láká nic netušícího uživatele, aby jeho prohlížeč provedl kód.

Jak nebezpečné jsou cross site request padělky (CSRF) útoky v WordPress ?

Jak bojovat proti útokům CSRF

Dobrá zpráva: Cross-Site Request Padělek je známý již věky. Vývojáři znají riziko a pracují konkrétně, jak se ho zbavit.

Špatná zpráva: Nemůžete se před tím chránit na technické stránce. Tá WordPress -Core je nyní poměrně dobře chráněn, a jak můžete vidět z probíhajících aktualizací, neustále na něm pracujeme. Stejně jako u jiných typů útoků se 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 dělat dobrou práci.

Konkrétně to znamená:

  • Instalátor 'ne příliš mnoho Plugins a pouze Plugins , které opravdu potřebujete
  • Dejte si pozor Plugins , které nebyly vývojáři po určitou dobu aktualizovány. To může skrýt nevyřešené chyby zabezpečení.
  • Informujte se předem o Plugins které instalujete, například o jejich kompatibilitě s jinými Plugins nebo WordPress verzi, kterou používáte (tak, aby Plugin aktualizace).
  • Aktualizujte svůj Plugins a wp-core. Vzhledem k tomu, že průběžné aktualizace jsou k dispozici k uzavření těchto chyb zabezpečení.
  • kritizujete phishing
  • Pokud si nejste jisti: Podívejte se na to Plugin v úložišti WP. Jak se recenze nezdaří, jaké byly největší problémy v minulosti a má Plugin může být uzavřena významná chyba zabezpečení?

Verdikt: CSRF je starý klobouk

Cross-Site Request Padělek byl asi od počátku digitálního věku. Kromě toho jsou čísla případů porovnána např. Brute Force Útoky extrémně malé.

To také potvrzuje, že Hodnocení OWASP: Předpokládá se, že útok je poměrně nízkorozšířený, snadno detekovatelný a ve velmi specifických případech je závažný pouze Je.

Nicméně je dobré vědět, jak útoky fungují. Protože útoky často fungují jen díky lidským chybám. Znovu a znovu, uživatelé otevřít e-maily ze zvědavosti, nebo klikněte na odkazy, které by lépe neotevřel.

Ať už jako uživatel nebo uživatel, nejlepší způsob, jak se chránit před cross-site Request Pagery je, aby tak učinily s výzkumem a nějaký zdravý rozum.

Jako správce systému společnost Tobias monitoruje naši infrastrukturu a hledá každý seřizovací šroub pro optimalizaci výkonu našich serverů. Vzhledem k jeho neúnavné úsilí, on je často také Slack k nalezení.

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