Projekt pro kurz PA018
(Advanced Topics in Information Technology Security):
Možnosti zneužití zranitelnosti XSS
se zaměřením na informační systémy
Milan Čermák
26. května 2013
Abstrakt
Následující text se zabývá webovou zranitelnosti Cross-Site Scripting, zkráceně XSS, která umožňuje vkládání útočníkova skriptu přímo do obsahu stránky. V textu jsou představeny možnosti
využití této chyby v kódu stránky potencionálním útočníkem. Text se zaměřuje hlavně na prostředí informačních systémů, převážně z důvodu jejich rozsáhlosti a obsahu spousty (pro útočníka)
zajímavých informací. Hlavní část zprávy se zabývá výsledky pokusu, který využívá objevenou
zranitelnost v Informačním systému Masarykovi univerzity. V rámci pokusu je vytvořen javascriptový kód a phishingový e-mail, který je rozeslán vybranému vzorku studentů ISu. Závěr zprávy se
pak věnuje způsobům obrany proti takovémuto útoku a to jak z pohledu uživatele, tak z pohledu
vývojáře.
1
Cross-Site Scripting (XSS)
Cross-Site Scripting je typ útoku, který umožňuje útočníkovi vložit do stránky svůj vlastní kód. Takováto zranitelnost útočníkovi umožňuje vložit na stránku závadný obsah (například urážlivé texty
nebo obrázky) nebo javascriptový kód, který se vykoná v prohlížeči oběti. Vložený kód následně
umožňuje útočníkovi například vykonání operací pod identitou uživatele (vyplnění formulářů, jako
je například přeposílání pošty), získat dočasný přístup k systému pod účtem uživatele (pomocí
cookies) nebo upravit chování stránky tak, aby byla využitelná k phishingovému útoku. Výhodou
(z pohledu útočníka) tohoto typu útoku je, že oběť přistupuje na webové stránky, které zná a kterým
důvěřuje, tudíž nepředpokládá, že by mohly být nějakým způsobem pozměněné nebo vykonávat
nebezpečný cizí kód.
Podle možného způsobu vložení útočníkova kódu rozlišujeme dva druhy zranitelnosti XSS: neperzistentní a perzistentní. V případě, že webová stránka do svého obsahu načítá některý parametr
z volání GET1 , bez toho aby jej validovala, mluvíme o neperzistentním XSS. Perzistentní je naopak
kód vložený pomocí nějakého formuláře na stránce a uložený tak, že při opětovném načtení se načte
i vložený kód. Příkladem jsou různá webová fóra, která nevalidují vstup a ukládají/zobrazují přesně
to co jim uživatel zadá. Takovýto typ útoku je nebezpečnější neboť útočník nepotřebuje šířit odkaz
jako v případě neperzistentního útoku.
Příklad využití chyby, kdy je hodnota parametru vložena do těla stránky:
∙ Správný odkaz:
http://www.citace.com/podporte_nas.php?ukol=1&odktitulek=Sponzoring
∙ Útočníkem upravené url:
http://www.citace.com/podporte_nas.php?ukol=1&odktitulek=<script>alert("XSS")
</script>
1
http://www.w3schools.com/tags/ref_httpmethods.asp
1
∙ Zdrojový kód stránky s neperzistentním XSS:
. . . <d i v i d =’ l e f t −l o n g ’>
<h2>< s c r i p t> a l e r t ( "XSS" )</ s c r i p t></ h2>
<p> . . .
Vložení kódu <script>...<script> není jediný způsob, kterým lze danou zranitelnost využít.
Často je implementováno několik obran, které mají zabránit XSS, ale které nejsou úplně účinné
a lze je obejít. Příklady různých možností vstupu, obcházející standardní kontrolu lze nalézt na
adrese https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet.
1.1
OWASP Top 10
Cross-Site Scripting je velmi rozšířená zranitelnost s potencionálně velkými možnostmi zneužití,
díky čemuž se pravidelně vyskytuje na nejvyšších místech uznávaného žebříčku deseti nejvíce nebezpečných hrozeb, tzv. OWASP Top 10.
OWASP2 je projekt zabývající se bezpečností webových aplikací. Cílem je poskytnout lidem,
kteří se zabývají vývojem webových aplikací povědomí o možných způsobech jejich napadnutí,
a hlavně vývojářům poskytuje návod, jak se těmto útokům bránit. Mezi jednu z nejznámějších
aktivit této organizace patří zveřejňování žebříčku aktuálních hrozeb podle jejich závažnosti a možného dopadu na web, tzv. OWASP Top Ten Project. V květnu tohoto roku byla vydána nová release
candidate verze pro rok 2013, která popisuje a řadí desítku následujících hrozeb:
1. Injection útoky (např. SQL injection)
2. Špatná autentizace a správa relace
3. Cross-Site Scripting (XSS)
4. Nezabezpečený přímý odkaz na vnitřní objekt
5. Chybná konfigurace
6. Únik citlivých dat
7. Chybějící řízení přístupu na funkční úrovni
8. Cross Site Request Forgery (CSRF)
9. Používání součástí, které mají známé zranitelnosti
10. Nevalidovaná přesměrování a předávání dat
V seznamu z roku 2007 byla zranitelnost XSS umístěna dokonce na prvním místě, jak je ale
vidět z letošního žebříčku, je jí stále přikládán velký význam. Ten je způsoben tím, že někteří
tvůrci webů tento typ zranitelnosti stále příliš neřeší, případně ošetřují jen některé vstupy a na
ostatní zapomínají. To je také částečně zapříčiněno tím, že si plně neuvědomují možné dopady,
které zneužití této zranitelnosti může mít. [2]
2
Možné útoky využívající zranitelnost XSS
I když to tak na první pohled nevypadá, zranitelnost Cross-Site Scripting může vést k mnoha v celku
závažným útokům. Pokud se zaměříme primárně na webové informační systémy, je potencionální
dopad útoku ještě mnohem větší. Webové informační systémy tvoří obvykle rozsáhlé webové stránky
se spoustou aplikací a služeb, které navštěvuje a využívá velké množství lidí, obvykle bez většího
informačního vzdělání. Tito lidé navštěvují systém několikrát za den a vůbec neočekávají, že by
mohl být nějakým způsobem upravený. Pro útočníka se tyto systémy stávají zajímavé také tím, že
obsahují velké množství informací a dat, které nejsou veřejně dostupné. Následující podkapitoly se
věnují potencionálními možnostmi, jak může útočník objevenou zranitelnost XSS zneužít.
2
The Open Web Application Security Project
2
2.1
Vložení nepůvodního textu
Využití XSS ke změně obsahu webu není příliš obvyklá metoda využívání zranitelnosti XSS, přesto
ji lze k tomu použít. Tento typ útoku lze očekávat spíš od aktivistů s různými politickými a jinými
cíli. Cílem jsou stránky veřejných institucí, u kterých se předpokládá, že mají velkou návštěvnost
a že takováto změna vyvolá větší mediální rozruch. Změny, které byly provedeny na webové stránce
útočníkem, lze velmi jednoduše zrušit smazáním vloženého kódu. Proto se k tomuto útoku používají
spíše jiné zranitelnosti, jako jsou SQL injection a podobné.
Obrázek 1: Změna obsahu webové stránky
2.2
Změna nastavení informačního systému
Pomocí vloženého javascriptového kódu je možné v prohlížeči vynutit vykonání takových akcí,
které povedou ke změně nastavení webové služby. Pomocí javascriptu lze vykonat takové akce,
které se pro informační systém jeví, jako by je prováděl sám uživatel, který ale o takovémto chování
vůbec neví. Výsledkem tak může být například přenastavení přeposílání e-mailové pošty, deaktivace
skrývání osobních informací (v případě Informačního systému Masarykovi univerzity to je například
zveřejnění známek za celé studium), změna bankovního účtu nebo vytvoření objednávky zboží spolu
se změnou adresy. Oběť se o provedení takového útoku obvykle vůbec nedoví nebo doví až ve chvíli,
kdy jsou změněné údaje zneužity.
2.3
Získání relace uživatele
Většina webových služeb využívá k udržení relace ukládání cookies3 , ve kterých je uložen jednoznačný identifikátor uživatele, umožňující přístup na stránky, dokud se uživatel neodhlásí a cookie
se tak nesmaže. Vložený javascript umožňuje získat soubor cookie pro stránku, kde je spuštěn,
a odeslat jej útočníkovi. Po získání si tak útočník může vytvořit kopii originální cookie a pro webovou stránku se následně s touto falešnou cookie tvářit jako regulérní, právě přihlášený uživatel.
Z důvodu usnadnění si přístupu, když navštěvují službu i několikrát za den, se uživatelé často neodhlašují nebo se odhlašují až na konci dne. Toto chování ale vede k tomu, že soubor cookie je stále
platný a útočník má tak dlouhodobý přístup k systému.
3
http://www.jakpsatweb.cz/enc/cookies.html
3
Obrázek 2: Výpis cookie pomoc javascript funkce alert()
2.4
Phishingový útok
Změna obsahu stránek pomocí útoku Cross-Site Scripting nemusí vést pouze k šíření aktivistických
zpráv, ale může sloužit i k vložení falešného přihlašovacího formuláře. Takto vložený formulář se pro
uživatele jeví jako standardní přihlašování, rozdíl ale je, že přihlašovací údaje jsou poslány na web
útočníka, kde jsou uloženy. Oproti tradičnímu phishingu, kdy útočník vytváří celé falešné stránky
a hostuje je pod url, která se co nejvíce snaží připomínat originální web, je tento útok proveden
přímo na originální stránce. Uživatel tak vidí url na kterou je zvyklý a pokud se nějak nebrání sám
zranitelnosti XSS, nemá možnost poznat, že přihlašovací formulář je falešný. Oproti klasickému
phishingu je tedy phishing za použití XSS mnohonásobně účinnější.
2.5
XSS Backdoor
Posledním z vybraných útoků je tzv. XSS Backdoor. Jedná se o velmi specifický útok, kdy po
navštívení stránky s vloženým odkazem, je na pozadí spuštěn kód, který umožní částečně ovládat
chování prohlížeče vzdáleně. Uživateli jsou originální stránky zobrazovány pomocí iframe4 , dokud
tedy uživatel nezavře nebo nepřepíše url, tak backdoor stále běží. Jedním z takovýchto backdoorů
je projekt BeEF5 , který nabízí útočníkovi spoustu funkcí, od logování stisknutých kláves a získání
cookies až po vyvolání falešného dotazu na instalaci Adobe Flash Player, který vede k instalaci
rozšíření pro Firefox nebo Chrome, umožňující ovládání i po uzavření stránky. [1]
Pro úspěch tohoto útoku je třeba udržet uživatele stále na stránce, kde je načten javascriptový
kód. Toho lze docílit například přepsáním všech odkazů na stránce a jejich načtením opět do iframe.
Toto chování je ale také největší slabinou útoku, neboť url zůstává stále stejná, i když se uživatel
již nachází na jiné stránce. Tohoto faktu si oběť útoku po čase jistě všimne, zpozorní a útok odhalí.
Obrázek 3: Uživatelské rozhraní frameworku BeEF
4
5
http://www.jakpsatweb.cz/iframe.html
The Browser Exploitation Framework
4
3 Zranitelnost XSS v Informačním systému Masarykovi univerzity
Informační systém Masarykovi univerzity (IS) je rozsáhlý systém, který obsahuje velké množství
informací jak o průběhu studia studentů (známky, studijní průměr zapsané předměty, ...), tak
i jejich osobní informace (adresa, telefon, seznam přátel) spolu s veškerou e-mailovou komunikací
(v případě, že si poštu nenechávají přeposílat někam jinam). Informační systém ale nevyužívají
pouze studenti, ale slouží i zaměstnancům (vkládání omluvenek na studijním oddělení) a učitelům,
kteří zde řídí veškerou agendu okolo předmětů, které vyučují. Zranitelnost takového systému je tedy
velmi kritická a může vést k závažným problémům. Z důvodu rozsáhlosti a obsahu dat, jsem tento
informační systém zvolil pro ukázku a otestování phishingového útoku využívající XSS zranitelnost.
Jak již bylo zmíněno, IS obsahuje velké množství aplikací, jako jsou například e-mail, webové
uložiště, agenda předmětů a zkoušek nebo odpovědníky, sloužící pro zkoušení studentů online. Právě
poslední zmíněná aplikace obsahovala chybu neperzistentního XSS, kdy v případě zadání špatné
cesty k odpovědníku byla v rámci chybové hlášky zobrazena hodnota atributu cesty z url: is.muni.
cz/auth/elearning/test_pruchod_el_student.pl?testurl=<script>alert("XSS")</script>.
Obrázek 4: Vykonání javascriptového kódu v Informačním systému Masarykovi univerzity
3.1
Javascript pro phishingový útok
Odhalenou zranitelnost jsem tedy využil k načtení vlastního javascriptového kódu. Tento kód okamžitě po načtení přepisuje stránku, na které se nachází a načítá stránku s chybovou hláškou o vnitřní
chybě IS s informací, že uživatel byl odhlášen a je vyžadováno jeho opětovné přihlášení. Jestliže
uživatel pokračoval na uvedený odkaz, místo originální přihlašovací stránky byla načtena falešná,
která vložené přihlašovací údaje posílá na logovací server. V případě reálného útoku by bylo možné
po přihlášení javascript ukončit a uživatele přesměrovat na domovskou adresu ISu. Uživatel by tedy
vůbec nenabyl podezření, že přihlašovací údaje byly poslány někam jinam.
3.2
Phishingový e-mail
Jak již bylo zmíněno je využit neperzistentní útok, z toho důvodu je potřeba k uživatelům dostat upravený odkaz. K tomu výborně slouží e-mailová aplikace v ISu, která zobrazuje i html tělo
zprávy. Díky tomu je možné ne jen poslat falešný e-mail (s podvrženou adresou), ale i skrýt podezřele dlouhý url odkaz. Text e-mailu se pak snaží vzbudit dojem, že oběť danou osobu zná:
Ahoj,
můžu tě poprosit o drobnou pomoc? Už nevím na koho se obrátit. Nejde mi otevřít tenhle odpovědník v ISu: https: // is. muni. cz/ auth/ elearning/ test_ pruchod_ el_ tudent. pl? fakulta=
1433; obdobi= 5763; studium= 601013; predmet= 687782; testurl= %2Fel% 2F1433% 2Fjaro2013%
2FJA012% 2Fstud% 2Fodp% 2Fodp-pov. qref a musím ho do zítra vyplnit. Na fóru předmětu nikdo
nereaguje a učitel taky ještě neodepsal. Odpovědník by měl být normálně přístupný všem. Můžeš to
prosím zkusit, jestli se ti chová taky tak divně? Nechci kvůli tomu dostat zbytečně Fko. Promiň, že
tě s tím otravuju, ale už fakt nevím na koho se obrátit.
Děkuju, uvidíme se v pátek ;)
5
Obrázek 5: Chybová hláška vyvolaná vloženým javascriptovým kódem
Z důvodu přítomnosti e-mailové aplikace přímo v ISu není nutné zprávu posílat z falešného/podvrhnutého účtu, ale stačí, aby jeden člověk daný odkaz otevřel a následně již javascript sám
může vygenerovat e-maily všem přátelům oběti. Těm pak přijde e-mail přímo od osoby, kterou
znají a více jí důvěřují, což výrazně zvyšuje potencionální úspěšnost útoku. Další výhodou takového útoku je, že se šíří sám bez přispění útočníka. Díky seznamům přátel se tak brzy dostává
téměř ke všem lidem, co využívají IS.
3.3
Omezení útoku
Vložení javascriptového kódu do stránky pomocí url odkazu je v prohlížečích Chrome a Internet
Explorer blokováno. Internet Explorer po rozkliknutí odkazu zobrazí hlášku, že stránka pravděpodobně obsahuje vložený kód a zastavuje jeho vykonání. Pro uživatele používající Internet Explorer
je tedy útok neúspěšný. Prohlížeč Chrome blokuje vložený javascriptový kód podobně jako Internet
Explorer. Rozdíl ale je, že pokud se soubor s kódem nachází na serveru, kde je volán, tak blokován není. Útočník tedy může využít další aplikaci ISu, kterou je webové uložiště, do kterého může
umístit svůj kód. Takto volaný javascript již v prohlížeči Chrome blokován není a útok je úspěšný.
4
Výsledky provedeného phishingového útoku
Pokusu se účastnilo 43 lidí, které znám a kteří používají Informační systém Masarykovi univerzity
(tito lidé o útoku nebyli informováni). Výsledky jsou proto částečně zkresleny, neboť většina z nich
studuje Fakultu informatiky a jsou více pozorní k jakémukoliv podezřelému chování. Pouze 9 lidí
z těchto 30 je z jiných fakult. Uvedený e-mail byl poslán s podvrženou adresou a jménem, které
se v ISu nenachází (z důvodu aby nebylo možné kontaktovat podvrženou adresu). Pokud uživatelé
otevřeli odkaz, byla tato aktivita zalogována stejně tak jako vyplnění přihlašovacích údajů, kde
bylo uloženo pouze vložené učo/přezdívka. Pokud uživatelé vyplnili přihlašovací údaje, byla jim
následně zobrazena informační stránka o podrobnostech útoku, kterého se stali terčem.
∙ Úspěšnost útoku
Z důvodu že e-mail byl odeslán z podvrhnuté e-mailové adresy od osoby, kterou lidé neznali,
je úspěšnost malá. Celkem 6 lidí kliklo na odkaz a pouze 2 z nich vyplnili přihlašovací údaje.
Z následného dotazníku vyplynuli tři hlavní důvody: „Nereaguji na e-maily od osoby, kterou
neznám“ , „E-maily prohlížím jinde jak v ISu a antispamový filtr je zablokoval“ a „Zpráva
byla příliš podezřelá“ .
6
∙ Potencionální úspěšnost útoku, pokud je známý odesílatel
Jako hlavní důvod proč lidé nereagovali na e-mail bylo, že neznali odesílatele. Z dotazníku
vyplynulo, že pokud by jim e-mail přišel od osoby, kterou znají (vyučující nebo kamarád),
odkaz by otevřeli (i když si někteří jsou vědomi toho, že adresu odesílatele lze podvrhnout).
Otevřeli byste odkaz, pokud by vám e-mail přišel od někoho, koho
znáte?
15%
Ano, otevřel bych odkaz
Ne, přesto bych odkaz
neotevřel
85%
∙ Vyplnění přihlašovacího formuláře
Další zajímavou otázkou je, zda by uživatelé vyplnili i přihlašovací formulář, pokud by již
otevřeli odkaz. Výsledkem je, že většina uživatelů, by přihlašovací údaje vyplnila.
Vyplnili byste přihlašovací údaje v případě, že byste odkaz
otevřeli?
Ano, bez váhání
34%
36%
Ano, ale váhal bych
Ne
30%
∙ Odhlašování z ISu
Uživatelé v rámci dotazníku byli také dotazováni, zda se odhlašují z ISu. Jak již bylo zmíněno
dříve v textu, pokud se uživatelé neodhlašují, tak při získání cookie útočníkem se prodlužuje
její platnost, dokud nevyprší daný časový limit.
Odhlašujete se z ISu?
24%
Ano, pokaždé
41%
Ne, jen zavřu stránku
Někdy ano někdy
35%
7
∙ Zkušenosti s phishingem
Jednou z otázek v dotazníku byla také otázka týkající se phishingu a zkušeností dotazovaných
s různými jejich formami.
Setkali jste si již někdy s phishingem?
Ne
5%
Ano, anglický text, na který jsem měl odpovědět s
vyplněnými údaji (heslo, PIN, ...)
18%
Ano, anglický text obsahující odkaz, který mě
přesměroval na falešnou stránku
36%
Ano, anglický text obsahující odkaz, který mě
přesměroval na upravenou originální stránku
5%
4%
Ano, český text, na který jsem měl odpovědět s
vyplněnými údaji (heslo, PIN, …)
Ano, český text obsahující odkaz, který mě
přesměroval na falešnou stránku
14%
18%
5
Ano, český text obsahující odkaz, který mě
přesměroval na upravenou originální stránku
Metody prevence XSS
Zranitelnosti XSS se může bránit jako tvůrce webové stránky, tak samotný uživatel. Samozřejmě,
primární role v ochraně leží na straně tvůrců webu, ale jak je znát podle OWASP žebříčku, stále
ne všichni dodržují doporučené nastavení, takže se uživatelé musí bránit sami.
5.1
Možnosti obrany pro samotného uživatele
Uživatel se útoku XSS může bránit pomocí vhodného prohlížeče. Tím je Internet Explorer, který
úspěšně blokuje jakýkoliv pokus o vložení kódu, který na stránku nepatří. Další možností je prohlížeč
Chrome, který jak bylo popsáno v předchozím textu, nechrání úplně a proti prezentovanému útoku
je bezbranný. Pokud uživatel používá prohlížeč Firefox, existuje pro něj doplněk NoScript Security
Suite6 , který dokáže útoku XSS zabránit podobně jako Internet Explorer. V tomto případě je ale
potřeba, aby uživatel o možnostech XSS věděl a věděl, že se má bránit. V základním sestavení
prohlížeče tento doplněk nainstalován není.
Dalšími možností obrany je zvýšená pozornost při jakémkoliv podezřelém chování webové stránky.
V případě, že se chování stránky jeví jakýmkoliv způsobem nestandardní, tak je třeba ji okamžitě
opustit. V případě neperzistentních útoků je třeba kontrolovat, kam odkazy skutečně odkazují a zda
neobsahují útočníkův kód. Pokud se jedná o phishing, platí základní pravidla, týkající se obecně
jakéhokoliv phishingu a to je, neklikat na odkaz v e-mailu od osob, které neznám nebo odkaz, který
od nich neočekávám.
5.2
Obrana na straně vývojáře webu
Základním pravidlem pro zabezpečení webových stránek je žádným způsobem nedůvěřovat jakémukoliv vstupu od uživatele. Ať se jedná o nahrávané soubory, dotazy ve vyhledávání nebo příspěvky
do fóra. Každý takovýto vstup může obsahovat speciální znaky, které umožní vložení příkazů v případě SQL injection nebo vlastního kódu. Nestačí ovšem tyto znaky pouze odfiltrovat seznamem
zakázaných znaků, protože nikdy není jistota, že jsou na seznamu všechny znaky. Doporučovaným
způsobem je povolit pouze znaky, které uživatel může vložit. Tím jsou obvykle alfanumerické znaky,
a pokud je třeba formátování, lze použít například BBCode7 .
6
7
https://addons.mozilla.org/cs/firefox/addon/noscript/
http://www.bbcode.org/
8
Při vytváření webových stránek je tedy vhodné dodržovat následující pravidla, definovaná v [3].
Dodržení těchto pravidel zaručí, že útočník nebude schopný žádným způsobem vložit vlastní kód
do obsahu stránky.
∙ Nikdy nevkládat nedůvěryhodná data do stránky s výjimkou jasně povolených
oblastí
Důvodem je, že v určitých částech kódu je obtížné obsah filtrovat případně escapovat nevhodné
znaky. Příkladem takových špatných oblastí jsou například:
<script>...<script> -- přímo ve skriptu
<!-- ... -->
-- v komentáři
<style> ... </style> -- v definici stylu
∙ Escapovat HTML znaky před jejich vložením do stránky
Pokud je třeba vložit nějaký text od uživatele do obsahu stránky, je třeba každý HTML znak,
který se v něm vyskytuje nahradit jeho bezpečnou variantou:
&
<
>
"
/
-->
-->
-->
-->
-->
&amp;
&lt;
&gt;
&quot;
&#x2F;
∙ Escapovat vkládané hodnoty atributů
Pokud je vstup od uživatele vkládán jako hodnota atributu (nejčastěji v případě vyhledávání,
kdy je zobrazen vyhledávaný dotaz), nelze spoléhat na to, že když je v uvozovkách, že se
neprovede. Tomuto omezení se může útočník velmi lehce vyhnout vložením znaků [mezera],
%, *, +, „ -, /, <, =, > a |. Z toho důvodu je třeba všechny tyto znaky zakázat nebo odfiltrovat
ze vstupu a nevypisovat.
∙ Escapovat vkládané hodnoty javascriptu
Jediné místo, kam je vhodné vkládat hodnoty od uživatele je mezi znaky uvozovek ("...").
Samozřejmostí je, že i takto vkládaný text je třeba validovat.
∙ Escapovat a striktně validovat data vkládaná do vlastnosti stylů
Útočník nemusí pouze vkládat kód <script></script>, ale může využít i událostí javascriptu
definovaných právě ve vlastnostech stylů. Mezi takové události patří například onLoad(),
onClick(), onMouseOver() nebo onSubmit().
∙ Escapování vkládané url
∙ Pro cookies použít tag HttpOnly
Nejedná se přímo o ochranu proti XSS, ale velmi s ní souvisí. V případě nastavení HttpOnly
u cookies zamezíme možnosti čtení cookies pomocí javascriptu v prohlížeči. Pokud se tedy
útočník pokouší získat relaci uživatele krádeží cookie, je mu to znemožněno.
Při vývoji webu je naprosto nevhodné psát si metody, které brání XSS sám, ale je lepší využít
funkce jazyka, které tutéž funkcionalitu nabízí a jsou již ozkoušeny a funkční. Pokud si vývojář
píše takovéto funkce sám, vždy hrozí, že na něco zapomene a útočník to pak bude moci zneužít.
Příkladem takto špatného filtrování je například sledování prvního html příkazu a jeho rušení, pokud
ale útočník vloží „’<aaaa><script>...</script>“ , je smazán pouze první html značka a další jsou
ponechány, tudíž se skript vykoná.
6
Shrnutí
V práci byla představena zranitelnost webových stránek umožňující vkládání útočníkova kódu a provedení tzv. Cross-Site Scripting (XSS) útoku. To že je tato chyba stránek stále široce rozšířená
dokazuje její zařazení na vrchních příčkách žebříčku OWASP Top 10, již od roku 2007. Z toho
důvodu je potřeba na ni stále upozorňovat vývojáře, aby se proti ní bránili. Na druhou stranu
chránit uživatele by měly i samotné prohlížeče, které v případě zjištění, že je vkládán cizí kód do
stránky, tento kód zablokují. Podle mého osobního názoru není žádný rozumný důvod, proč by měl
být vykonávaný skript předávaný jako parametr url.
9
Druhá část práce byla zaměřena již na konkrétní případ využití zranitelnosti XSS pro potřeby
phishingu. Byl vytvořen javascriptový kód předstírající chybu v Informačním systému Masarykovi
univerzity a následně vyžádány přihlašovací údaje. Tento kód byl následně vložen pomocí chyby
v aplikaci odpovědníků, přes hodnotu atributu url, přímo do zobrazené stránky. V současné době je
již zranitelnost opravena, chování javascriptového kódu je tedy možné si vyzkoušet na adrese http:
//cermmik.mzf.cz/share/odpovednik.html. Pro šíření odkazu s vloženým kódem byl rozeslán 43
lidem e-mail (od neexistující osoby), který zkoušel úspěšnost takového útoku.
Z důvodu, že většina ze 43 lidí studuje Fakultu informatiky a jsou tak více obezřetní, nebyl útok
příliš úspěšný. Jak ale vyplynulo z dotazníku, pokud by jim stejný odkaz přišel od někoho, koho znají
(učitel nebo kamarád), odkaz by otevřeli a ve většině případů i vyplnili přihlašovací údaje. Díky
možnosti webového uložiště přímo pod adresou is.muni.cz bylo možné provést útok i v prohlížeči
Chrome, který v případě že skript pochází ze stejné url jako je navštívená stránka, tento skript
neblokuje. Jediný prohlížeč, který tak plně chrání uživatele před útokem XSS je Internet Explorer.
Přestože většina lidí, kterým byl zaslán phishingový e-mail, studuje Fakultu informatiky, tak
o útoku XSS vůbec neví nebo ví jen minimum informací. S reálným útokem XSS se žádný z nich
zatím ještě nesetkal. Z toho důvodu pro ně bylo zajímavé vyzkoušet si, co takový útok všechno
umožní a jak na něj zareagují. Aby se člověk mohl takovýmto útokům bránit, je třeba jej ne jen
teoreticky znát, ale nejlépe si ho i bezpečně vyzkoušet a zkusit si, jak se s ním vypořádat. Ze
zpětné vazby vyplynulo, že přesně tento účel byl splněn a že respondenti alespoň částečně budou
obezřetnější i na webových stránkách, o kterých si myslí, že jsou bezpečné, jako je třeba právě
Informační systém Masarykovi univerzity.
Reference
[1] ALCORN, Wade. BINDSHELL.NET. BeEF: The Browser Exploitation Framework [online].
[cit. 2013-05-26]. Dostupné z: <http://beefproject.com/>.
[2] OWASP FOUNDATION. OWASP: The Open Web Application Security Project [online]. [cit.
2013-05-26]. Dostupné z: <https://www.owasp.org>.
[3] WILLIAMS, Jeff, Jim MANICO a Eoin KEARY. XSS (Cross Site Scripting) Prevention Cheat
Sheet. OWASP FOUNDATION. OWASP: The Open Web Application Security Project [online]. [cit. 2013-05-26]. Dostupné z: <https://www.owasp.org/index.php/XSS_(Cross_Site_
Scripting)_Prevention_Cheat_Sheet>.
10
Download

Možnosti zneužití zranitelnosti XSS v informačních