© 2013 All rights reserved.
2

How to: XSS (Cross site scripting) hacking?

Na téma XSS (Cross Site Scripting) bylo napsáno již mnoho textů. Jedná se o poměrně starý typ útoku, ale i tak si ani v dnešní době mnozí programátoři neuvědomují jeho nebezpečí.

XSS neboli Cross Site Scripting není nic jiného, než to, že se útočník snaží dostat svůj kód do vašeho kódu, tedy kódu, který generuje prohlížeč. Většinou to musí udělat přes vstupy jako jsou URL adresy, formulářové inputy a nebo vstupní textová pole.

Předpoklady

Takový útok může ovšem provést opravdu jenom v případě že je vstupní prvek je nezabezpečený a jeho kód tím pádem nebude při odeslání nebo výpisu upraven.
V praxi často upozorňuji zákazníky na XSS chyby na jejich webech. Bohužel se mi už několikrát od firem, které web dělali dostane odpovědi, že XSS není útok, a že se zabezpečením nemá nic společného. Většinou chyby nakonec opraví, ale zákazníka ukonejší tím, že všechno bylo pořádku už předtím.

Bohužel opak je pravdou a XSS lze považovat za opravdový typ útoku i když se tak na první pohled možná nejeví.

XSS útok může být proveden několika způsoby. Nejjednodušší je ten, kdy útočník upraví URL adresu nebo vstupní pole odesílané přes GET (čili taky URL adresu) a v kombinaci s javascriptovým innerHTML(nebo jinak) upravuje jednotlivé části stránek. Tohle já opravdu nepovažuji za útok, i když samozřejmě na webu chyby jsou a musí být opraveny. Web by nikdy neměl dělat nic, s čím by programátor nepočítal.

Samotné PHP nabízí spoustu funkcí, pomocí nichž lze takovým „modifikacím“ webu předcházet a pomocí kterých bezpečně ošetříme uživatelské vstupy.

Předcházení útoku

Většinou je na programátorovi, aby správně navrhl aplikaci nebo systém, který uživatelé vstupy zpracovává. Není možné se spoléhat na majitele webu, který nemá pravděpodobně o funkčnosti ani páru. Takže celá odpovědnost padá na programátora, nebo popřípadě celou firmu, která celý koncept zrealizovala.

V PHP není složité se proti XSS bránit. Bohužel se většina programátorů opět spoléhá na to, že je server správně nastaven, nebo je nastaven stejně jako jejich localhost, kde mají chyby ošetřeny To je taky dost často kámen úrazu. Narážím přímo na direktivu

Magic_Quotes_GPC, která se stará o přidání zpětných lomítek k nepovoleným znakům (i když to možná zacházím do SQL Injection). Pokud si nejsme zcela jisti nastavením této direktivy, nebo popřípadě vyvíjíme systém, který bude běžet na více serverech, je dobré vstupní proměnné ošetřit například nějak takto:

Tím dosáhneme toho, že proměnné dostaneme ze vstupu přesně v takovém tvaru v jakém je uživatel odeslal a máme jistotu, že v nich nebudou žádné znaky navíc. Takové proměnné si můžeme potom upravit s jistotou v jakém jsou tvaru bez závislosti nastavení serveru.

Další důležité funkce, které musí každý programátor znát, nebo alespoň funkce jim podobné jsou samozřejmě HtmlSpecialChars, nebo Strip_Tags, kterými nahradíme nebo smažeme odesílané nepovolené znaky. Takto ošetřený kód se stává pro útočníka mnohem obtížnější.
Samozřejmostí je nastavení Error_Reporting na hodnotu 0, aby nedocházelo k výpisu chybových hlášení a útočník nemohl odhalit slabiny webu. Web se musí za každou cenu snažit tvářit tak, že s danou chybou počítal a i když na ni není připravený, nesmí to dát znát.

How to

Doposud jsem psal pouze o případě, kdy se útočník snaží přes různé vstupy propašovat do výsledné stránky svůj falešný obsah pouze k modifikaci výsledného kódu. Tyto druhy útoků nejsou ani tak moc nebezpečné, útočník může maximálně pošpinit dobré jméno webu, ale většinou se mu nepodaří smazat žádná data nebo nadělat jiné problémy.

Dalším druhem útoku, který si ukážeme na konkrétním případě, je situace, kdy se útočník snaží získat z webu informace pomocí Cross Site Scriptingu. V tomto případě se nebude snažit upravit výsledný kód, který vrací prohlížeč (nebude se to snažit dát znát), ale bude se snažit do kódu propašovat svůj vlastní kód tak, aby o něm nikdo nevěděl za účelem úniku informací.

Konkrétně mluvím o kradení Cookies, kdy toto je u špatně zabezpečeného webu velice nebezpečné a velice jednoduché ze strany útočníka.

Já jsem si pro svůj útok vybral web Kompletne.cz, který jsem na chybu upozornil a v této chvíli by měla být již opravena.

Hned na první pohled mě na webu zaujaly profily, kdy si po zaregistrování můžete vyplnit informace o svém účtu a zobrazit je ostatním uživatelům. Tyto profily byly pro tento web osudným a všechno opět byla chyba programátora a všechno byla chyba pouze v XSS a špatně zabezpečených inputech ve formulářích.

Po prozkoumání formuláře jsem udělal první test. Do textového pole Město/adresa jsem vložil HTML kód a znaky jako uvozovky a apostrofy abych vypozoroval co se s nimi po odeslání stane. Formulář jsem odeslal a prozkoumal se na výsledek.

Správně se zobrazili HTML tagy, přičemž u apostrofů a uvozovek byly zpětné lomítka (alespoň že tak). Ovšem pro to, abych web „hacknul“ to úplně stačilo.

Editoval jsem tedy znova svůj profil a vložil sem HTML kód, ve kterém se načítal obrázek o nulových rozměrech. V SRC atributu byl odkaz na můj web, konkrétně soubor .php, kam se jako parametr v URL adrese předávalo document.cookies.

V PHP soubor docházelo ke zpracování a ukládání identifikátoru do souboru:

Velice jednoduché a účinné jak uvidíte.

Nyní stačilo jenom čekat, až si některý přihlášený administrátor prohlídne stránku s profily, což netrvalo dlouho:

Poslední věc, kterou jsem musel udělat byla nastavit tento identifikátor pro daný web ve svém prohlížeči, což už je otázka několika kliknutí a kopírování. Tímto postupem jsem získal administrační práva a byl přihlášen jako jeden z administrátorů.

No výsledek vypadal asi takto:




Dodávám že jsem na webu nic nesmazal, ale pouze upozornil adminy na chybu, které se dopustili.

Závěrem

Nechtěl by jsem aby tento článek byl nějakým návodem na to, jak obcházet systém a jak využívat dané chyby a ani by jsem nechtěl, aby byl chápán jako vychloubání. Chtěl by jsem spíše poukázat na to, že i tak podceňovaný typ útoku jako je XSS, kterého se mimochodem programátor dopustí velice jednoduše, může ve výsledném efektu natropit hromadu nepříjemností.

Webů, které se tímto druhem chyby mohou pochlubit najdete i na českém internetu tisíce!

Comments are closed for this page

Ukradnutie session este nie je take zavazne. Ved si zoberme co ste mal v tom textaku. Len session id a to bola sesna lubovolneho uzivatela, ktory si pozrel Vas profil. Vobec to nemusel byt admin a este ku tomu clovek musi stihnut pozuzit toto id kym sa dany uzivate neodhlasi co znamena sediet nad tym textakom neustale. Kazdopadne je to velka chyba. Myslim ze kazdy programator co robi nieco na web by mal byt s XSS vysporiadany.

byla to sice session libovolneho uzivatele, ale bylo jasne, ze se tam casem obevi session ID admina.
A kdyz se nepouziva ani session_regenerate_i d, tak si vemte ze se vetsina uzivatelu ani neodhlasuje, tak to potom neni zase takovy problem, se prihlasit kdykoli.
Nad textakem jsem ani tak moc nesedel. Mrknul jsem se tam za pul hodinky, kdy uz tam bylo nekolik desitek session ID, a nebyl problem vybrat to administratorovo, podle poctu opakovani.

About
Hi, i am programmer from the Czech Republic. I love web development (Ruby, Ruby on Rails, PHP, Nette) and iOS development (Objective-C, Cocoa).
To cooperate, here is my phone:
+420 608 836