Útoky typu Cross-Site Scripting

Transcription

1 Masarykova univerzita Fakulta informatiky Útoky typu Cross-Site Scripting Bakalárska práca Oliver Chorvát Brno, jar 2010

2 Prehlásenie Prehlasujem, že táto bakalárska práca je mojím pôvodným autorským dielom, ktoré som vypracoval samostatne. Všetky zdroje, pramene a literatúru, ktoré som pri vypracovaní používal alebo z nich čerpal, v práci riadne citujem s uvedením úplného odkazu na príslušný zdroj. Vedúci práce: RNDr. Marek Kumpošt, Ph.D.

3 Zhrnutie Útoky typu Cross-Site Scripting sú rozšírenou hrozbou, ktorá ohrozuje v podstate všetky webové aplikácie. Napriek tomu, že táto hrozba je nespochybniteľná, mnoho webových aplikácií a ich tvorcov ju neberú dostatočne vážne. Teoretická časť popisuje mechanizmus tohto útoku, spôsoby detekcie slabého miesta v aplikácii, hrozby a možnosti obrany proti útoku. Praktická časť potom demonštruje ukážky útokov, ako aj spôsoby obrany proti nim a ich implementácie.

4 Kľúčové slová Cross-site scripting, input filtering, malicious scripts, script injection, threats, vulnerability detection, web application vulnerability.

5 Obsah 1 Úvod Mechanizmus útokov XSS Rozdelenie Perzistentné útoky XSS Neperzistentné útoky XSS Útoky XSS založené na DOM Detekcia zraniteľností XSS Manuálne odhaľovanie zraniteľností XSS Ukážka manuálneho odhalenia zraniteľnosti Nástroje na manuálne vyhľadávanie zraniteľností Nástroje na sledovanie komunikácie Automatizované odhaľovanie zraniteľností XSS Nástroje na automatizované vyhľadávanie zraniteľností Databáza zraniteľných stránok Hrozby spôsobované útokmi XSS Hrozby proti dôvernosti Odchytávanie informácií Hrozby proti identite Krádež identity Vnútenie identity CSRF Podvodné hrozby Poplašné správy Phishing Hrozby proti systému užívateľa Obrana proti útokom Obrana na strane užívateľa Obozretnosť Blokovanie Javascriptu Obrana na strane aplikácie Neúčinné metódy obrany Účinné metódy obrany Obchádzanie filtrov... 17

6 6 Praktická časť Obsah praktickej časti Návod na použitie aplikácií Testovanie príkladov Záver A Obsah CD Literatúra... 24

7 Kapitola 1 Úvod Táto bakalárska práca pojednáva o útokoch typu Cross-Site Scripting proti webovým aplikáciám. História tohto druhu útokov siaha dlhé roky dozadu. Údajne prvé zmienky o týchto útokoch, ako aj pomenovanie Cross-Site Scripting vzniklo okolo roku Je nutné si však uvedomiť, že história týchto záležitostí sa neeviduje centralizovane, teda je možné, že podobné prípady sa vyskytli aj skôr. Napriek tomu, že útoky typu Cross-Site Scripting sú staršie, než snáď všetok dnes používaný software, stále patria medzi najpopulárnejšie útoky proti webovým aplikáciám. Pôvodne boli tieto útoky označované ako CSS skratka dlhšieho pomenovania, neskôr sa však zaužívaná skratka zmenila na XSS, ktorú používam v celom texte práce. Bolo tomu tak z dôvodu konfliktu so skratkou pre Cascading Style Sheets 2. Pri čítaní práce by sa čitateľ mohol zamyslieť, prečo sa tieto útoku označujú ako Cross-Site Scripting. Scripting, teda skriptovanie ešte zmysel dáva, keďže sa pri útokoch používajú skriptovacie jazyky. So spojením Cross-Site, ktoré by malo označovať nejaké dianie naprieč stránkami, je už trocha problém. Hneď v prvej kapitole je popísaný jednoduchý útok, ktorý sa odohráva celý na jednej stránke, teda by sa zdalo že toto pomenovanie nie je presné. Pravda je taká, že toto pomenovanie má historické dôvody a nebolo zmenené, aj keď už v súčasnej situácii nie je príliš popisné. V dávnych dobách Cross-Site Scriptingu bolo totiž obvyklé, že stránky pozostávali s rámcov HTML prvkov <frame>. Vtedy bolo možné manipuláciou obsahu niektorého z rámcov dosiahnuť vykonanie skriptu z inej stránky (preto Cross-Site). V súčasnej dobre sa takéto scenáre prakticky už nevyskytujú, pomenovanie však zostalo. Pod týmto názvom sa teda skrývajú útoky založené na vkladaní skriptovacieho kódu tam, kam nepatrí podrobnejší popis v kapitole o mechanizme útoku. Modernejšie a popisnejšie by sa táto trieda útokov dala označiť názvom script injection, ako je uvedené aj v niektorej literatúre [1]. Samotná práca je štruktúrovaná tak aby umožnila čo najjednoduchšie pochopenie problematiky a dopadov na webové aplikácie, ako aj bežných užívateľov. Hneď v druhej kapitole je podrobne popísaný mechanizmus týchto útokov ako fungujú a tiež ako je možné ich kategorizovať. Ďalšia kapitola sa zaoberá odhaľovaním zraniteľných miest webových aplikácií voči tomuto typu útokov. Popísané sú manuálne aj automatizované metódy a k ním tiež príslušné nástroje. Na konci kapitoly je uvedená on-line databáza zraniteľných stránok, na ktorých je postupy možné vyskúšať. V kapitole o hrozbách spôsobovaných týmto druhom útokov je popísané, čo všetko sa môže stať, ak takýto útok bude úspešne vykonaný. Hrozby sú rozdelené podľa aktív, alebo tiež hodnôt, ktoré ohrozujú. Posledná kapitola sa zaoberá obranou proti týmto útokom, či už obozretným správaním na strane užívateľov, alebo filtrovaním a dôsledným programovaním na strane aplikácie. Tiež sú popísané bežné chyby obranných mechanizmov a ako možno tieto chybné mechanizmy obísť. Praktická časť práce potom obsahuje ukážkovú aplikáciu, ktorá popísané znalosti z teoretickej časti demonštruje v praxi. Jej súčasťou sú modelové aplikácie a scenáre útokov ich funkčné implementácie aj teoretický popis a kategorizácia. Tiež nechýbajú ukážky efektívnej aj neefektívnej obrany

8 Kapitola 2 Mechanizmus útokov XSS Pri skúmaní každého útoku je dôležité čo najpresnejšie pochopiť, ako daný útok funguje. Pri útokoch XSS je táto úloha o to náročnejšia, že útoky XSS nie sú v skutočnosti variácie jedného princípu útoku v mnohých prevedeniach, ale jedná sa o celú kategóriu odlišných útokov. Keby sme teda chceli definovať XSS všeobecne, môžeme povedať len toľko, že Cross-site Scripting je útočná technika založená na vykonaní útočníkom poskytnutého kódu užívateľovou inštanciou prehliadača. Inštancia prehliadača môže byť nie len obvyklý webový prehliadač, ale aj súčasť inej aplikácie, napríklad čítačky RSS, alebo ového klienta. Inkriminovaný kód je obvykle písaný v HTML a Javascripte, ale môže sa jednať aj o VBScript, ActiveX, Javu, Flash, alebo čokoľvek iné, čo prehliadač podporuje. [2] Už len z tohto krátkeho popisu vidíme, že XSS môže postihovať nie len webové aplikácie, ale aj ostatný software využívajúci internet, a že jazykom na realizáciu útoku nemusí byť len Javascript, ale môže to byť aj jeden z ostatných uvedených. Keď toto porovnáme napríklad so známym útokom SQL injection, ktorý je zameraný proti webovým aplikáciám s databázou, a využíva zásadne jazyk SQL, zistíme, že hrozba XSS má omnoho širší záber. Táto práca sa však zaoberá výhradne útokmi XSS proti webovým aplikáciám, čo záber zas trochu zužuje. Pre definitívne porovnanie týchto dvoch hrozieb však môžeme nahliadnuť do dokumentu OWASP Top 10 [3], ktorý predstavuje rebríček najzávažnejších zraniteľností webových aplikácií. V tomto rebríčku sú na prvom mieste zraniteľnosti XSS, na druhom potom tzv. injekčné zraniteľnosti, ako napríklad SQL injection. 2.1 Rozdelenie Je teda zrejmé, že útoky XSS sú veľká skupina. Táto sa však delí podľa toho, akým spôsobom sa škodlivý kód dostane k prehliadaču. Toto rozdelenie je ale z hľadiska webovej aplikácie, nie z hľadiska užívateľa. Teda nie je podstatné, či užívateľovi došiel odkaz so škodlivým kódom om, alebo či na neho klikol. Podstatné pre toto rozdelenie je, či je škodlivý kód v aplikácii uložený, či sa objaví iba v odpovedi na požiadavky, ktoré škodlivý kód obsahujú, alebo sa vyskytuje v súvislosti s manipuláciou HTML dokumentov Perzistentné útoky XSS Perzistentné (persistent), uložené (stored), alebo statické (static). To všetko sú označenia pre skupinu útokov XSS, pri ktorej je škodlivý kód uložený vo webovej aplikácii. Logicky sa teda tento útok skladá z dvoch častí vloženie škodlivého kódu a jeho zobrazenie užívateľovi. Na to aby bolo kód možné do aplikácie vložiť, musí aplikácia takúto funkcionalitu poskytovať, teda musí v nej byť miesto, kde môže užívateľ uložiť svoj vstup tak aby sa zobrazil aj iným. Spravidla to bývajú diskusné fóra, sociálne siete, inzercia, komentáre k článkom atď. Na toto miesto v zraniteľnej aplikácii vloží útočník škodlivý kód. Toto samo o sebe by ale bolo úplne bezvýznamné, keby sa tento kód nikomu neodoslal, teda keby sa stránka s kódom nezobrazila ostatným užívateľom. To už je druhá fáza útoku, pri ktorej dochádza k samotnému vykonaniu škodlivého kódu v kontexte prehliadača užívateľa. Útok potom pretrváva, dokým sa kompromitovaná stránka neprestane zobrazovať, alebo dokým škodlivý kód niekto neodstráni. 2

9 Príklad perzistentného útoku XSS Ako bolo uvedené v popise tejto kategórie, typickým takto zraniteľným miestom sú napríklad diskusné fóra. V lepších diskusných fórach je možné ku každému príspevku vkladať aj podpis užívateľa, ktorý je možné si plne prispôsobiť pomocou HTML. V tom prípade, za predpokladu že je dané fórum zraniteľné, by k úspešnému vykonaniu perzistentného útoku XSS stačilo do podpisu vložiť nasledujúci kus kódu: <SCRIPT> alert('xss'); </SCRIPT> Neperzistentné útoky XSS Alebo tiež odrazené (reflected), či dynamické (dynamic). Táto skupina útokov sa od tej predošlej líši tým, že pri ani po vykonaní útoku škodlivý kód nezostáva v aplikácii 3. Škodlivý kód býva aplikácii podstrčený ako parameter v URL. Aplikácia, ak je zraniteľná, použije škodlivý kód v parametri na vytvorenie obsahu, ktorý, keď sa zobrazí užívateľovi spôsobí vykonanie kódu. Obvyklým zraniteľným miestom, ktoré takto funguje sú vyhľadávače, ktoré pri zobrazovaní výsledkov pripomenú hľadaný výraz, môže sa jednať ale aj o prihlasovacie formuláre, alebo hocijaké iné formuláre, ktorých vstup sa niekde zobrazuje. K užívateľovi sa potom odkaz obsahujúci škodlivý kód môže dostať napríklad pomocou u, alebo iným podobným spôsobom. V prípade, že užívateľ na odkaz klikne alebo ho bude iným spôsobom nasledovať, stane sa obeťou útoku. Ale ani opatrný užívateľ, ktorý by na takýto nedôveryhodný odkaz neklikol, nie je v bezpečí. Stačí, aby takýto opatrný užívateľ navštívil stránku, ktorá jeho prehliadač donúti odkaz nasledovať. Toto je možné dosiahnuť napríklad pomocou HTML prvku <iframe>. Príklad neperzistentného útoku XSS Túto kategóriu je vhodné ilustrovať na typickom príklade vyhľadávači. Stačí mať zraniteľný vyhľadávač, ktorý zobrazuje hľadaný výraz aj na stránke s výsledkami. Ak tento vyhľadávač posiela hľadaný výraz ako parameter v URL, je zraniteľnosť možné využiť napríklad nasledujúcim odkazom: pt> Podrobnejší popis tohto modelového vyhľadávača je v podkapitole Ukážka manuálneho odhalenia zraniteľnosti. Opatrného užívateľa by bolo možné napadnúť vložením nasledujúceho kódu do tela dôveryhodnej stránky: <iframe src= " pt> "/> 3 Neberieme do úvahy serverové logy a podobné záznamy. 3

10 Mohlo by sa zdať, že sa jedná o perzistentný útok, ale nie je tomu tak. Útočí sa totiž voči aplikácii na adrese hladaj.sk, a tam škodlivý kód uložený nie je. Dôveryhodná stránka, na ktorej je tento kód uložený teda slúži iba ako médium, ktoré dopraví škodlivý kód k užívateľovi Útoky XSS založené na DOM DOM Document Object Model je platformovo a jazykovo nezávislé rozhranie, ktoré umožňuje programom a skriptom dynamicky čítať a meniť obsah, štruktúru a štýl dokumentov. Dokument môže byť ďalej spracovaný a výsledky spracovania môžu byť včlenené späť do prezentovanej stránky [4]. V kontexte útokov XSS sú podstatné hlavne útočníkom manipulovateľné objekty DOM ako napríklad document.location, document.url alebo document.referrer, s ktorými sa dá pracovať napríklad pomocou Javascriptu. Útok spočíva v zneužití zraniteľnosti spôsobenej nie bezpečnou prácou s týmito objektmi pomocou skriptov v stránke. Špecifickým rysom tejto kategórie útokov je, že za istých okolností je možné útok vykonať bez toho, aby sa škodlivý kód akýmkoľvek spôsobom dostal na server, voči ktorého užívateľovi útok prebieha. Príklad útoku XSS založeného na DOM Reálne príklady útokov a zraniteľností tohto typu sú o niečo menej časté než u predošlých dvoch, a tiež nemusia byť na prvý pohľad ľahko odhaliteľné. Je tomu tak preto, že tieto zraniteľnosti bývajú spôsobené logickou chybou v skriptoch už existujúcich v stránke, ktorú je treba identifikovať. V zjednodušenom príklade si môžeme predstaviť, že webová aplikácia pomocou Javascriptu prečíta meno užívateľa z URL a vloží ho do stránky. Vypísanie mena by mal na starosti nasledujúci kód: <SCRIPT> var pos=document.url.indexof("name=")+5; document.write(document.url.substring(pos,document.url.length)); </SCRIPT> Útok by sa potom dal vykonať napríklad nasledujúcim odkazom: ipt> Na odkaze je pozoruhodné to, že namiesto klasického znaku pre uvedenie parametrov? je použitý znak #. Pre prehliadač # znamená, že ďalšia časť reťazca je tzv. fragment. To znamená, že škodlivý kód, ktorý sa za týmto znakom nachádza nebude na server odoslaný, ale kód bude napriek tomu vložený do tela stránky. To je zrejmé z uvedeného skriptu, ktorý nesleduje, či je v URL?, ale riadi sa iba výskytom podreťazca name=. 4

11 Kapitola 3 Detekcia zraniteľností XSS Zraniteľnosť všeobecne sa definuje ako slabé miesto aktíva alebo skupiny aktív, ktoré môže byť využité jednou alebo viacerými hrozbami, tj. k vykonaniu útoku [5]. V tomto prípade budeme pod aktívom alebo skupinou aktív rozumieť webové aplikácie a pod jednou alebo viacerými hrozbami práve XSS. Zostáva už len spresniť, čo by mohlo byť tým slabým miestom. Ako bolo vysvetlené v úvode, útoky XSS sú založené na vykonaní skriptového kódu na mieste, ktoré k tomu pôvodne nebolo určené. Zraniteľnosť XSS je teda také miesto vo webovej aplikácii, ktoré umožní vykonať skriptový kód, ktorý spravidla nepochádza zo samotnej webovej aplikácie, ale bol na toto miesto vložený útočníkom. Práve podľa metódy vloženia tohto kódu sú v úvode útoky XSS rozdelené. Prvým krokom k úspešnému vykonaniu útoku a takisto prvým krokom k úspešnému zabezpečeniu webovej aplikácie proti týmto útokom je zistiť, či je daná aplikácia zraniteľná. V praxi sa toto dá robiť manuálne, alebo automatizovane pomocou na to určených nástrojov. 3.1 Manuálne odhaľovanie zraniteľností XSS V prípade, že je predmetom záujmu kvalitne otestovať danú webovú aplikáciu na zraniteľnosti XSS, nie je to možné spoľahlivo vykonať automatizovane. Automatizované nástroje síce môžu odhaliť niektoré známe, alebo veľmi nápadné zraniteľnosti, ale v žiadnom prípade by nebolo rozumné usúdiť, že ak automatizovaný nástroj nič nenašiel, aplikácia nie je zraniteľná. V praxi, hlavne pri väčších aplikáciách, sa toto odhaľovanie zraniteľností robí za pomoci nástrojov popísaných v ďalšej podkapitole, mechanizmus je však podobný ako pri ručnej činnosti za pomoci webového prehliadača. Toto odhaľovanie obvykle pozostáva z dvoch častí. Jednak je treba zvoliť, ktoré miesto vo webovej aplikácii bude otestované, a potom, akým skriptom. Zraniteľné miesta vo webovej aplikácii sú obvykle tie, ktoré užívateľom vložený obsah použijú k vytvoreniu obsahu nejakej novej stránky. Obvykle sú to vyhľadávacie formuláre, knihy návštev, profily užívateľov v sociálnych sieťach a podobne. Voľba skriptu, respektíve jeho sofistikovanosť závisí od miery ochrany, ktorú daná webová aplikácia má Ukážka manuálneho odhalenia zraniteľnosti Majme jednoduchú aplikáciu na adrese hladaj.sk umožňujúcu vyhľadávanie v obsahu. Ako bolo uvedené, vyhľadávanie v stránkach býva často slabým miestom, teda je vhodné ho otestovať. Zadanie vstupu vyhľadávaču umožňuje nasledujúci kód na stránke index.php: <form action="najdi.php" method="get"> <input type="text" name="dotaz"/> <input type="submit" value="submit" /> </form> Stránka hladaj.php potom vykoná vyhľadávanie. Dobrým zvykom vyhľadávačov však býva, že okrem výsledkov zobrazia aj čo sa vlastne vyhľadávalo. Odolnosť tohto miesta voči útoku XSS sa dá otestovať vložením napríklad nasledujúceho vyhľadávacieho zadania: text<script>alert('xss');</script> 5

12 Tento reťazec obsahuje okrem zadania vyhľadávania kúsok Javascriptového kódu, ktorý, ak sa vykoná, zobrazí upozornenie s textom XSS. Ako bolo uvedené na začiatku kapitoly, zraniteľnosť XSS je miesto, ktoré umožní vykonanie cudzieho kódu. V tomto príklade by to bola nasledujúca časť kódu: <h2>hľadali ste: <?php echo $_GET['dotaz'];?></h2> Na výslednej stránke by sa teda, ako bolo pôvodne zamýšľané, zobrazil nadpis so zadaním vyhľadávania, ale jeho Javascriptová časť by sa vložila do kódu stránky a vykonala. Z toho teda vyplýva, že táto časť aplikácie je zraniteľná. 3.2 Nástroje na manuálne vyhľadávanie zraniteľností Vyhľadávanie zraniteľností obvykle neprebieha len za pomoci webového prehliadača. Existuje množstvo nástrojov, ktoré túto činnosť dokážu uľahčiť, prípadne poskytujú možnosti, ktoré prehliadač nie. V nasledujúcom texte uvediem užitočné nástroje rozdelené podľa funkcionality ktorú poskytujú Nástroje na sledovanie komunikácie Pri testovaní zraniteľností XSS je dôležité mať čo najpresnejší prehľad o komunikácii medzi klientom a serverom. Všetky detaily sú podstatné. Normálne webové prehliadače obvykle zobrazujú len to čo majú, nie však všetko, čo by mohli. Ak chceme vidieť úplne všetko, musíme komunikáciu nejakým spôsobom monitorovať. Jednou možnosťou je použiť špeciálny webový proxy server, cez ktorý budeme komunikáciu smerovať. Tento server potom umožňuje prezerať všetky požiadavky aj odpovede, prípadne ich dokáže pozdržať, zahodiť, či zmeniť. Medzi takéto programy patrí napríklad trocha starší Achilles 4, alebo momentálne ešte stále vyvíjaný Burp Proxy 5. Burp Proxy ponúka okrem základnej funkcionality aj prehľadné rozhranie, ktoré napríklad zobrazuje všetky parametre, a podobne. Ďalšou možnosťou je použiť niektoré z pluginov pre Firefox 6, ktoré majú podobnú funkcionalitu. Veľmi jednoduchým a efektívnym pluginom je Live HTTP Headers 7, ktorý umožňuje sledovať komunikáciu medzi prehliadačom a serverom na úrovni protokolu HTTP, ako aj vytvárať a odosielať pozmenené repliky HTTP požiadavkov. Pri väčšom objeme zachytávanej komunikácie alebo dlhých hlavičkách s množstvom parametrov sa dá ľahko stratiť prehľad, ale ako jednoduchý nástroj okamžite pripravený na použitie plní tento plugin svoju funkciu dobre. Obsiahlejším pluginom s viac možnosťami je Tamper Data 8. Tento, ako názov napovedá, umožňuje nie len komunikáciu monitorovať, ale zachytávať a meniť pred tým, než bude odoslaná. Tiež je možné zachytenú komunikáciu filtrovať a tak v nej nestrácať prehľad. Ponúkaná funkcionalita je v podstate rovnaká ako u proxy serverov, s tým rozdielom, že sa jedná o plugin, ktorý je integrovaný do prehliadača

13 3.3 Automatizované odhaľovanie zraniteľností XSS Automatizované odhaľovanie týchto zraniteľností môže prebiehať dvoma spôsobmi. Buď sa overí, či webový server používa nejaký zraniteľný framework 9, alebo sa automaticky otestujú všetky vstupné formuláre, či sú na útoky XSS zraniteľné. 3.4 Nástroje na automatizované vyhľadávanie zraniteľností Dobrým príkladom, ktorý implementuje obe metódy odhaľovania je bezpečnostný skener Nessus 10. Tento okrem mnohých iných funkcií poskytuje aj testovanie webových aplikácií na zraniteľnosti XSS. Pri práci s Nessusom je možné zvoliť testovacie pluginy, teda konkrétne testy ktoré budú vykonané. Jednoduchší a časovo menej náročný je test, ktorý zistí, či webová aplikácia používa nejaký redakčný systém, systém na správu diskusných fór, alebo iný systém, ktorý nejakým spôsobom obhospodaruje obsah webu. Ak je takýto systém zistený, porovná sa jeho verzia s databázou zraniteľných verzií týchto systémov. V prípade, že nainštalovaná verzia systému sa nachádza medzi zraniteľnými, vyplýva z toho, že testovaná aplikácia bude takisto zraniteľná. 3.4 Databáza zraniteľných stránok Pre iniciatívnych čitateľov, ktorí by mali záujem si odhaľovanie zraniteľností vyskúšať na reálnych aplikáciách, uvádzam nasledovný odkaz. Jedná sa o databázu všemožných stránok či webových aplikácií zraniteľných práve útokmi typu XSS. Komunita užívateľov do databázy prispieva objavovaním stále nových zraniteľných stránok, vždy aj s kódom, s ktorým sa im podarilo zraniteľnosť preukázať. Zaujímavý je tiež celkový počet odhalených zraniteľných stránok cez , z čoho opravených bolo údajne pod Pre tých ktorí chcú experimentovať, alebo snáď by chceli vidieť dôkaz, že hrozba útokov XSS je skutočne reálna databáza sa nachádza na 9 Rozšíriteľné softwarové prostredie poskytujúce základnú funkcionalitu Údaje zo dňa

14 Kapitola 4 Hrozby spôsobované útokmi XSS V predošlej kapitole je popísané, ako je možné odhaliť, že nejaká aplikácia je útokmi XSS zraniteľná. V tejto kapitole sú uvedené rozličné hrozby, ktoré táto zraniteľnosť spôsobuje. Známejšie a frekventovanejšie býva zneužitie tejto zraniteľnosti v neprospech užívateľov danej aplikácie, je však možné ohroziť aj aplikáciu samotnú, prípadne aj s ňou spojenú infraštruktúru. Na prvý pohľad by sa mohlo zdať logické rozdeliť hrozby na tie, ktoré poškodzujú užívateľov aplikácie a tie, ktoré poškodzujú aplikáciu samotnú. Vzhľadom na povahu útokov XSS to však nie je optimálne riešenie. Odhliadnuc od toho, akou cestou sa útok uskutočnil, skoro vždy sú poškodené obe strany. Pre názornosť uvediem príklad: útočník zistí prihlasovacie a osobné údaje užívateľov e-shopu. Je jasné, že poškodení sú užívatelia, prinajmenšom tým, že bolo narušené ich súkromie. Na druhej strane si však treba uvedomiť, že e-shop stratil dôveryhodnosť, klientelu, a môže mať aj právne problémy. Rozhodol som sa teda v tejto práci deliť hrozby podľa toho, akým spôsobom zúčastnené strany ohrozujú. 4.1 Hrozby proti dôvernosti Pod dôvernosťou sa rozumie nasledovné informácie sú prístupné alebo poskytnuté iba tým, ktorí sú k tomu oprávnení [5]. Hrozby proti dôvernosti teda sú také hrozby, pri ktorých sa niekto nepovolaný môže dostať k informáciám, ktoré mu nie sú určené. V prípade útokov XSS sa jedná hlavne o informácie prenášané medzi obeťou útoku a zraniteľnou aplikáciou. Tiež je však možné získať prístup k súborom v počítači obete útoku a prehliadať si, či dokonca manipulovať ich obsah Odchytávanie informácií Pomocou Javascriptu je možné pristupovať k dátam v HTML stránkach. Nie je teda problém tieto dáta poslať na server ovládaný útočníkom. Týmto spôsobom je možné získať prístup k obsahu komunikácie medzi serverom a užívateľom, vrátane napríklad prihlasovacie údaje, osobné údaje, čísla kreditných kariet a podobne. Je však nutné útočný kód napísať aplikácii na mieru, teda je treba správne zvoliť napríklad mená formulárov, ktorých obsah sa má zachytiť Iná metóda odchytávania informácií spočíva v použití keyloggeru kódu, ktorý zachytáva stlačené klávesy. Odlišnosť od predošlej formy útoku spočíva v tom, že útok je aktívny práve tak dlho, ako samotná stránka na ktorej sa kód nachádza. V prípade statických stránok, kde sa užívateľ v aplikácii pohybuje prechodmi medzi stránkami, táto forma nie je od tej predošlej o moc zaujímavejšia. Ak sa však jedná o aplikáciu používajúcu napríklad AJAX 12, môže útok pretrvať aj počas celej relácie, čo je o mnoho nebezpečnejšie ako odchytenie jednej stránky. 4.2 Hrozby proti identite Identita užívateľa voči webovej aplikácii je to, čo ho z pohľadu aplikácie odlišuje od ostatných užívateľov. Ak je identita zmanipulovaná, ukradnutá, či iným spôsobom napadnutá, má to za následok to, že útočník smie konať v mene napadnutého užívateľa, prípadne užívateľ môže vykonať niečo, čo by si neprial

15 4.2.1 Krádež identity Najbežnejší a najobvyklejší útok proti identite bude pravdepodobne jej krádež. Túto je aj prostredníctvom útokov XSS jednoduché realizovať. Keďže veľké množstvo webových aplikácií si ukladá identitu užívateľa do cookie (spravidla tzv. session cookie), nie je problém sa k tejto identite pomocou Javascriptu dostať. Rovnako nie je problém ju odoslať serveru kontrolovanému útočníkom. Útočník potom môže upraviť svoj session cookie tak, aby vystupoval pod ukradnutou identitou. Na strane aplikácie je však možné sa proti takejto krádeži identity brániť, to už však nespadá do náplne tejto práce, ale skôr do oblasti zabezpečenia relácií Vnútenie identity Menej bežný útok proti identite je jej vnútenie. Na prvý pohľad možno ani nie je zrejmé, čo by sa týmto útokom dalo dosiahnuť. Je pravda, že útočník by asi ťažko niečo získal, keby niekomu vnútil svoju identitu voči nejakej webovej aplikácii, aj keď to je tiež možné. Napríklad sa dá uvažovať o systéme, ktorý za zadanie nejakého tajného kódu, ako napríklad zľavového kupónu, poskytne užívateľovi výhodu. V tom prípade by malo zmysel, aby útočník v momente zadávania kódu vnútil obeti svoju identitu a získal tak výhodu. Druhá vec je, prečo by to robil, keď by mohol rovno zachytiť ten kód. Zmysluplnejšie použitie tohto útoku je, keď útočník chce zamaskovať pôvod iného útoku. Napríklad chce s pomocou identity ukradnutej v predošlom útoku vykonať nejakú operáciu, ale nechce zviditeľniť svoju IP adresu. Pomocou útoku XSS teda zmanipuluje session cookie novej obete, aby obsahoval ukradnutú identitu. Pomocou ďalšieho útoku, napríklad CSRF pomocou XSS, potom zamýšľanú operáciu utajene vykoná CSRF Teda cross-site request forgery. Takto sa označujú útoky, pri ktorých útočník vytvorí URL, ktoré predstavuje vykonanie nejakej akcie v aplikácii a toto podstrčí obeti. Alebo, v prípade kombinácie s XSS ho vloží do samotnej aplikácie, často vo forme obrázku, a tak nedáva obeti šancu sa brániť. Proti tomuto útoku však existuje jednoduchá obrana na strane aplikácie. Pred každou dôležitou akciou opakovať autentizáciu užívateľa. Teda aby nebolo možné jedným kliknutím akciu vykonať. 4.3 Podvodné hrozby Tento druh hrozieb je založený na tom, že útočník vloží kód či informácie do stránky, ktorá je inak užívateľom považovaná za dôveryhodnú. Týmto spôsobom je možné užívateľov oklamať, alebo aj od nich získať dôverné informácie Poplašné správy Javascriptový kód nie len, že má prístup k dátam obsiahnutým v HTML stránke, môže ich aj meniť. Keď útočník takto zmení obsah, prípadne len časť, informácie na nejakom navštevovanom spravodajskom serveri, vznikne poplašná správa, ktorú si okamžite prečíta množstvo ľudí. Navyše ju budú považovať za dôveryhodnú, preto že sa objavila na dôveryhodnom serveri ktorý pravidelne navštevujú. Účelom týchto útokov môže byť spôsobenie znepokojenia, zmätku, prípadne šírenie klamlivých informácií, alebo poškodenie dobrej povesti a dôveryhodnosti serveru. 9

16 4.3.2 Phishing Jedná sa o podvodné y, ktorých cieľom je vylákať od obetí dôverné informácie, obvykle prihlasovacie údaje alebo čísla kreditných kariet. Tento druh útokov funguje aj nezávisle od útokov XSS, v kombinácii s nimi je však ešte nebezpečnejší. Čisto phishingové útoky sa obvykle odohrávajú na doméne pod kontrolou útočníka, ktorý dúfa, že si to obete nevšimnú. Napríklad je meno domény skoro identické s originálom, len je tam o jedno písmenko menej či viac. V prípade kombinácie útokov phishing a XSS sa však odchytenie údajov odohráva na napadnutej doméne. Jej časť, do ktorej sa majú údaje zadať je pri útoku nahradená, napríklad pomocou prvku <iframe>, formulárom útočníka, ktorý údaje ukradne. Táto forma útoku je podstatne nebezpečná preto, že napríklad ani správne nastavené HTTPS spojenie s platným certifikátom nie je funkčnou ochranou. Užívatelia teda majú falošný pocit bezpečia, čo útočníkom ešte viac pomáha. 4.4 Hrozby proti systému užívateľa Všetky doposiaľ uvedené hrozby mali jedno spoločné, a to že sa nejakým spôsobom jednalo o ohrozenie kvality komunikácie medzi užívateľom a aplikáciou. Okrem toho je však možné útokmi XSS ohroziť aj samotný systém užívateľa. K tomu je možné použiť napríklad ovládacie prvky ActiveX, prípadne Java applet. Tieto prvky majú prístup k súborovému systému počítača, na ktorom sú spustené, a teda predstavujú významnú hrozbu. V závislosti od nastavení môžu tieto prvky byť zakázané, a vždy ich je treba explicitne povoliť. Nemenej podstatné je, že vytvorenie takéhoto útočného kódu je náročnejšie, ako kódu Javascript používaného v ostatných útokoch. 10

17 Kapitola 5 Obrana proti útokom Ako proti väčšine kybernetických útokov, tak aj proti útokom typu XSS je žiaduce a možné efektívne sa brániť. V tomto prípade je však situácia o niečo zložitejšia ako u iných útokov proti webovým aplikáciám napr. SQL injection. Útok SQL injection je totiž útok proti samotnej aplikácii a jej databázy, zatiaľ čo XSS útočí na aplikáciu a jej užívateľov. V prípade SQL injection je teda možné povedať, že útok bol voči danej aplikácii úspešný, ale u XSS útokov mohol byť útok úspešný jedine voči aplikácii a niektorým jej užívateľom. 5.1 Obrana na strane užívateľa Kľúčové samozrejme je zabezpečenie na strane aplikácie aby nebola zraniteľná. Ak ale zraniteľná je, nemusí to okamžite znamenať, že prípadný útok bude úspešný aj proti všetkým užívateľom aplikácie Obozretnosť Hneď na začiatku tejto podkapitoly musím upozorniť, že obozretnosť v tomto zmysle slova je trocha niečo iné, ako v každodennom živote. Je to preto, že väčšina počítačových užívateľov nemá o žiadnych hackeroch ani ich útokoch poňatia, prípadne si myslia že nie sú dostatočne dôležití alebo zaujímaví, aby na nich niekto takto útočil. V ideálnom prípade by táto forma obozretnosti bola samozrejmosťou rovnako ako rozhliadnuť sa na prechode, či nejde auto. Keďže tomu tak ale nie je, a v najbližšej dobre ani nebude, nie je možné z hľadiska vývojárov aplikácie s takýmto správaním počítať. Ak ale má užívateľ záujem o svoju bezpečnosť a vie na čo má dávať pozor, môže značne zvýšiť svoju šancu ubrániť sa nie len útokom typu XSS ale aj iným internetovým nebezpečenstvám a podvodom. Napríklad neperzistentné útoky typu XSS sú často založené na URL, ktoré musí užívateľ navštíviť, aby sa kód spustil. Ak je užívateľ výnimočne obozretný a URL nenavštívi 13, nič sa nestane. Podobne môže uvedomelosť ochrániť užívateľa pred útokmi, ktoré napríklad vytvoria <iframe> cez celú stránku a v ňom sledujú aktivity užívateľa. Ak si ale ten všimne, že sa počas jeho prehliadania webu nemení URL, môže ešte mať šancu útok odvrátiť Blokovanie Javascriptu Úplne na začiatku práce je uvedené, že útoky XSS sú založené na tom, že prehliadač vykoná nejaký cudzí kód. Logická cesta teda je snažiť sa, aby sa ten kód nedostal na miesto, kde by ho prehliadač vykonal, ale je tu ešte aj iná možnosť. Znemožniť prehliadaču vykonávanie tohto kódu. Úplné zablokovanie Javascriptu V každom serióznom webovom prehliadači existuje možnosť Javascript vypnúť. Toto užívateľa úplne ochráni pred útokmi XSS založenými na Javascripte, ktorých je prevažná väčšina. Zároveň to ale znemožní využívať všemožnú funkcionalitu, ktorú Javascript na mnohých stránkach poskytuje kvôli tomu vlastne existuje. Štatistika 14 na obrázku 1 ukazuje, že Javascript nemá 13 Nie vždy je ale neklikanie na URL zárukou bezpečia. Napríklad v prípade vloženia URL do HTML u pomocou <iframe> bude URL prehliadačom "navštívená" pri otváraní u

18 zapnutých len 6 % užívateľov. Medzi obvyklé dôvody patrí napríklad reštriktívne nastavenie na firemných počítačoch, nízka výpočtová kapacita mobilných zariadení, strach pred zneužitím napríklad práve útokom XSS, alebo prehliadač, ktorý Javascript nepodporuje. Dobrým príkladom takéhoto prehliadaču je Lynx 15 textový webový prehliadač, ktorý sa dá spustiť v Linuxe v príkazovom riadku. Javascript % Javascript <1.2 0% Nepoužíva Javascript 6% Obr. 1: použitie Javascriptu Selektívne zablokovanie Javascriptu V dnešnej dobe interaktívnych webových aplikácií by sa málokto chcel pripraviť o možnosti, ktoré mu aplikácie, aj pomocou Javascriptu, ponúkajú. Kompromisom medzi bezpečnosťou vďaka úplnému vypnutiu Javascriptu a využívaním interaktívnych aplikácií naplno je selektívne zablokovanie skriptov. V prehliadači Firefox je toto možné dosiahnuť pluginom NoScript 16. Tento plugin spočiatku zablokuje všetky skripty, a počas používania umožňuje povoliť dôveryhodné skripty z dôveryhodných stránok. Dôležité je, že to funguje práve takto a nie naopak, teda princíp whitelist a nie blackilst. V prípade blacklistu (napríklad plugin YesScript 17 ) totiž nejde o žiadne zvýšenie bezpečnosti (plugin YesScript ani zvýšenie bezpečnosti neuvádza, ale neznalých užívateľov by mohla zlákať jeho jednoduchosť, nenáročnosť a zdanlivo rovnaká funkcionalita). Útoky XSS bývajú spravidla neočakávane, teda ich nie je možné vopred umiestniť na blacklist. Okrem tejto základnej funkcionality plugin NoScript poskytuje aj ochranu špeciálne proti útokom typu XSS 18 neperzistentným a založeným na DOM. Táto funkcia však nie je dokonalá, teda občas vyprodukuje nejaké falošné poplachy, ktoré môžu bežného užívateľa vyplašiť. Preto, a aj preto, že je pre normálne fungovanie treba nastaviť whitelist si myslím, že tento plugin je vhodný pre trocha pokročilejších užívateľov

19 5.2 Obrana na strane aplikácie Predošlá podkapitola bola skôr o pokročilejších alebo pozornejších užívateľoch, ktorí sa môžu o svoju bezpečnosť aspoň trocha pričiniť. Všetci ostatní užívatelia sú však odkázaní na prácu vývojárov aplikácie. Ich úlohou je jednak uvedomiť si, v čom presne hrozba útokov typu XSS spočíva a vyprodukovať také ochranné mechanizmy pre svoju aplikáciu, aby užívatelia boli podľa možností čo najviac v bezpečí Neúčinné metódy obrany Mohlo by sa zdať nezmyselné písať o neúčinných metódach obrany. Keď je niečo neúčinné, načo o tom písať? Treba si však uvedomiť, že jedna z najhorších vecí v bezpečnosti vôbec je falošný pocit bezpečia. Preto v tejto podkapitole uvediem metódy, ktoré žiadnu ochranu proti útokom typu XSS neposkytujú. HTTPS HTTPS, teda zabezpečená verzia protokolu HTTP je oproti základnej verzii v mnohom bezpečnejšia. Poskytuje napríklad ochranu proti odchytávaniu komunikácie a tiež istotu, že užívateľ skutočne komunikuje s tým správnym serverom. Prehliadače obvykle o tomto bezpečí užívateľa uisťujú tým, že ukážu nejakú ikonku zámku a prehlásia, že spojenie je bezpečné. Problém však je v tom, že HTTPS chráni iba pred útokmi na nižšej vrstve OSI modelu, čo XSS rozhodne nie je. Dalo by sa to ilustrovať na príklade nášho modelového vyhľadávača. Je totiž úplne jedno, či je odkaz: pt> alebo ipt> Oba rovnako obsahujú škodlivý kód a v oboch prípadoch sa rovnako vykoná. V podstate je to úplne jasné, napriek tomu môže hlavne neznalý užívateľ považovať HTTPS za synonymum bezpečnosti a podľahnúť falošnému pocitu istoty. Obzvlášť nebezpečná je kombinácia HTTPS a XSS pri phishingových útokoch. Jednou z obvyklých poučiek býva, že podvodné stránky mávajú inú doménu, ďalšou potom, že ak platí HTTPS certifikát, užívateľ skutočne komunikuje s pravou stránkou a jeho komunikáciu nikto neodpočúva. Vďaka XSS však ani jedno nemusí byť pravda. Filtre na strane klienta Jedným z bežných využití Javascriptu je okrem spríjemňovania webových stránok aj validácia vstupov užívateľa. Napríklad v registračnom formuláre je možné overiť, či do políčka užívateľ zadal niečo, čo obsahuje Ak nie, môže mu validačný skript v momente potvrdenia namiesto odoslania zobraziť upozornenie, že je chybne vyplnený. Dôležité je však uvedomiť si účel tohto opatrenia. Tým účelom nie je chrániť server pred nezmyslami, ale spríjemniť interakciu užívateľovi bude na chybu upozornený prakticky okamžite a pred odoslaním stránky. Keby však odhodlaný užívateľ chcel, nie je problém validačný skript vypnúť, zablokovať, alebo inak obísť. Potom je možné poslať aj neočakávané údaje. Ak teda vývojári 13

20 aplikácie zanedbali základnú zásadu neveriť vstupom od užívateľa a neimplementovali ďalšiu validáciu na strane servera, bude možné do aplikácie vložiť neplatné údaje. Veľmi podobne ako s validáciou je to aj s filtrovaním. Filtre sú zásadným prvkom obrany proti útokom XSS a budú podrobne rozobrané v ďalšej podkapitole. Svoj účel však môžu plniť jedine v tom prípade ak sú na strane serveru a útočník nemá možnosť ich jednoducho vyradiť obídením nejakého skriptu. Takáto vysoko neúčinná metóda obrany je našťastie veľmi vzácna, snáď preto, že jej nasadenie svedčí o úplnom nepochopení podstaty týchto útokov Účinné metódy obrany Základnými metódami obrany proti útokom XSS na strane webových aplikácií je filtrovanie a kódovanie vstupu či výstupu. Filtrovanie má na starosti, aby sa do webovej aplikácie nedostali nežiaduce reťazce ako napríklad HTML značky či ich atribúty, prípadne javascriptový kód. Kódovanie má potom za úlohu zakódovať obsah stránky tak, aby sa prevzatý vstup nevykonal ako kód, ale napríklad zobrazil ako text. Filtrovanie Filtrovanie, prípadne tiež validácia vstupu je metóda, ktorá má zaistiť, že aplikácia na vstupe dostane zmysluplný obsah, ktorý vyhovuje ďalšej logike aplikácie. Na to, aby akékoľvek filtrovanie alebo validácia boli možné, je treba mať jasnú predstavu o tom, čo je povolený vstup a čo už nie. Túto predstavu treba potom nejako pretvoriť do pravidiel a tie implementovať do aplikácie. Od zložitosti týchto pravidiel je potom závislá aj náročnosť implementácie a tiež možnosť, že sa vyskytne chyba. Na úvod začnime jednoduchým príkladom formulárové pole pre vloženie telefónneho čísla. Ako je možné validovať toto pole a odfiltrovať nežiaduci vstup? Prvým krokom je definovať, čo rozumieme pod pojmom telefónne číslo. Dalo by sa napríklad povedať, že telefónne číslo je reťazec, ktorý obsahuje iba číslice a znaky +, - a. V jazyku PHP 19 by šlo výraz, ktorý rozhoduje, či reťazec splňuje toto pravidlo zapísať napríklad nasledovne: <?php if (preg_match("/[0-9\-+ ]*/", $telefonnecislo, $matches)) { echo "Platné číslo"; } else { echo "Neplatné číslo"; }?> Samozrejme tento regulárny výraz nie je optimálny na rozpoznávanie telefónnych čísel, ale zodpovedá pravidlu uvedenému vyššie. Hlavné v tejto situácii ale je, že táto veľmi jednoduchá metóda spoľahlivo odfiltruje hocijaký škodlivý kód na jeho zapísanie by totiž boli treba písmená alebo iné špeciálne znaky, ktoré tento filter neprepustí Pre jeho rozšírenosť medzi menej komplexnými webovými aplikáciami a tiež relatívnu jednoduchosť budem v práci používať práve PHP. 14

21 Veľmi podobné sú polia, ktoré sú určené napríklad na zadanie mena, ovej adresy, bydliska, či vyhľadávaného výrazu. Všade tu sa dá vystačiť s písmenami, číslicami a obmedzenou množinou špeciálnych znakov, ktorá je bezpečná 20. Z hľadiska filtrovania sú však zaujímavejšie vstupy, ktoré užívatelia používajú napríklad na vytváranie svojich profilov v sociálnych sieťach alebo na písanie príspevkov do diskusií. Tu už totiž obvykle neplatí, že by sa dalo bez problémov vystačiť len s obyčajným textom. Rozšírené funkcie webových aplikácií často umožňujú užívateľom vkladať obrázky, prípadne iné prvky HTML. V tom prípade už nie je možné jednoducho odfiltrovať špeciálne znaky, ale je nutné vstup podrobnejšie analyzovať a rozhodnúť, čo je ešte povolené. Ďalšia vec, ktorú je pri filtrovaní treba premyslieť je, ako sa zachovať v prípade nepovoleného vstupu. Prvá možnosť je vstup proste odmietnuť, druhá potom pokúsiť sa vstup upraviť tak, aby bol povolený. Odmietnutie je určite bezpečnejšie a jednoduchšie, na druhej strane ale automatické opravenie vstupu je užívateľsky prívetivejšie. Napríklad do vyhľadávaču Google 21 je možné zadať všeličo možné, vyhľadávač nepovolené znaky odfiltruje a vyhľadáva len text. Výhody takéhoto správania snáď netreba viac vysvetľovať. Takéto selektívne filtrovanie je však zas o niečo náročnejšie než samotné rozhodnutie, či vstup je alebo nie je platný. Typickým príkladom logického zlyhania je naprogramovať filter tak, aby ním vstup prešiel len raz a výsledok bol automaticky považovaný za správne odfiltrovaný. Toto je možné ilustrovať na príklade jednoduchého filtru, ktorý zo vstupu odstraňuje reťazec <script>. Ak by tento filter fungoval jednorázovo tzn. by neopakoval proces filtrovania viac krát, dal by sa jednoducho obísť vstupom napríklad <scr<script>ipt>. S odmietnutím však tiež môže byť problém ak aplikácia neplatný vstup znova zobrazí. Napríklad by chybová správa vyzerala takto: Zadali ste nesprávne telefónne číslo:<script>...</script>. V tomto prípade je síce fajn, že sú neplatné vstupy odfiltrované, na druhej strane ale na tomto mieste vzniká neperzistentná zraniteľnosť XSS. Kódovanie Filtrovanie samozrejme nie je jediná možnosť, ako zabrániť zobrazovaniu škodlivého užívateľského vstupu späť na stránkach. Súčasťou filtrovania je samozrejme aj kódovanie a dekódovanie vstupu bez neho by filtrovanie nemalo význam. Opäť príklad pre vykonanie útoku XSS je dôležité do aplikácie dopraviť znak <, ktorý býva napríklad súčasťou HTML značky <script>. Nasledujúce reťazce (oddelené medzerami) sú všetko reprezentáciou tohto znaku v nejakom kódovaní [6]: < %3C &lt < &LT &LT; &#60 &#060 &#0060 &#00060 &# &# < < < < < < &#x3c &#x03c &#x003c &#x0003c &#x00003c &#x000003c < < < < < < &#X3c &#X03c &#X003c &#X0003c &#X00003c &#X000003c < < < < < < &#x3c &#x03c &#x003c &#x0003c &#x00003c &#x000003c < < < < < < &#X3C &#X03C &#X003C &#X0003C &#X00003C 20 Bezpečnými množinami špeciálnych znakov sa v tomto kontexte rozumejú také, ktoré v kombinácii s číslami a písmenami nie sú dostatočné na to, aby umožnili vykonať útok XSS

22 &#X000003C < < < < < < \x3c \x3c \u003c \u003c Kódovania sú: ASCII, HTML entity, Hex pre HTML, Dec pre HTML, Unicode. Také množstvo kombinácií existuje z toho dôvodu, že rôzne štandardy považujú za platné aj znaky so zbytočným počtom úvodných núl. To je dôležité, pretože ak sú filtrom odstraňované iba znaky zakódované bez týchto núl, je filter možné obísť. Kódovanie prebieha na vstupe aj na výstupe. Dobrou ilustráciou pre tento princíp je webová aplikácia, do ktorej je možné na vstupe vkladať HTML kód. Takýto vstup sa musí pri vložení vhodne zakódovať, aby sa dal bezproblémovo vložiť do databázy, a pri zobrazení sa zas musí zakódovať tak, aby sa zobrazoval ako text a nie aby sa stal súčasťou kódu samotnej stránky. Omnoho komplexnejší sa však problém kódovania stáva u veľkých webových aplikácií v ktorých môže napríklad nejaký obsah byť zobrazený na viacerých miestach v každom prípade musí byť samozrejme príslušne zakódovaný. V neposlednom rade je podstatné aj to, že ak sa nejakým spôsobom dostal do aplikácie škodlivý kód, práve kódovanie výstupu rozhoduje o tom, či sa vloží do stránky ako škodlivý kód, alebo iba zobrazí ako neškodný text. V praxi sa obvykle jedná o to nahradiť potenciálne škodlivé špeciálne znaky HTML entitami. V prípade útokov XSS sú zaujímavé hlavne tieto (4): HTML entita Zobrazený znak " " &apos; ' < < > > & & Ukážka implementácie filtru v PHP Jedna z ukážok v praktickej časti práce znázorňuje jednoduchú aplikáciu, ktorá je odolná voči útokom typu XSS. Napriek tomu však situácia nie je úplne triviálna a aplikácia akceptuje prvok HTML, konkrétne obrázky <img> s atribútmi src, width a height, ktoré vyjadrujú cestu k obrázku, jeho šírku a výšku. Toto je dosiahnuté implementáciou vstupného filtru, ktorý vyhovuje požiadavkám formulovaným v predošlom texte. Implementácia použitá v práci bola získaná zo stránky PHP Classes 22, autorom je Daniel Morris a kolektív. Samotný filter je okrem ukážkového súboru index.php jediná PHP trieda, ktorú je treba do aplikácie vložiť, napríklad pomocou include(). O tom, ktoré HTML značky a atribúty sú povolené, a ktoré budú odfiltrované rozhodujú parametre predávané konštruktoru. Jeho hlavička vyzerá nasledovne: public function construct($tagsarray = array(), $attrarray = array(), $tagsmethod = 0, $attrmethod = 0, $xssauto = 1) {...} Prvé dve polia obsahujú HTML značky a ich atribúty, ďalšie dve čísla určujú význam týchto polí. 0 znamená, že prvky v poliach sú jediné povolené (princíp whitelist), 1 znamená, že práve tieto prvky sú neprípustné (princíp blacklist). Posledný parameter riadi automatické filtrovanie

23 nebezpečných značiek a atribútov 23 1 znamená zapnúť, 0 vypnúť. Po vytvorení objektu triedy InputFilter inicializovaného príslušnými parametrami stačí vždy keď je to potreba zavolať metódu process($source). V premennej $source sa nachádza vstupný reťazec alebo pole, ktoré je treba filtrovať. Po vykonaní metódy je v tej istej premennej vrátený výsledný odfiltrovaný reťazec. V prípade ukážkovej aplikácie je filter inicializovaný nasledovne: $tags = array('img'); $attrs = array('src','width','height'); $myfilter = new InputFilter($tags, $attrs, 0, 0, 1); Obchádzanie filtrov Okrem amatérskych stránok, ktoré vytvárali ľudia len tak pre zábavu vo svojom voľnom čase má dnes už snáď každá webová aplikácia nejaký obranný mechanizmus proti útokom na ňu. Keďže na prvých dvoch miestach rebríčku zraniteľností OWASP (1) sú útoky typu XSS a útoky ako napríklad SQL Injection niet divu, že mnohé z nich sa bránia práve proti nim. Filtre sú účinné proti obom týmto útokom, napríklad tak, že odstraňujú zo vstupu špeciálne znaky ako napríklad ", ' a iné. Zdalo by sa teda, že skoro všetky aplikácie sa proti útokom typu XSS bránia. Druhá vec však je, koľko z nich sa bráni úspešne. To už závisí od toho, nakoľko vývojári aplikácie porozumeli princípu tohto útoku a koľko možností a variant útoku brali do úvahy, ale aj od toho, ako komplexná daná aplikácia je. Ak sa totiž jedná o jednoduchú aplikáciu, ktorá napríklad funguje ako on-line kalkulačka, situácia je triviálna. Stačí vstup filtrovať tak, že nebude povolené nič okrem číslic. V tom prípade stačia základné znalosti regulárnych výrazov na vytvorenie bezchybného 24 filtru, ktorý nebude možné nijako obísť ani oklamať, nebude možné tam prepašovať žiaden iný znak a teda ani vykonať útok XSS. Teda určite môže existovať aj filter, ktorý sa obísť nedá, ale čím je aplikácia komplexnejšia a čím rozsiahlejšia je množina pravidiel potrebných na posúdenie vhodnosti vstupu, tým náročnejšie je taký filter vytvoriť, alebo vôbec posúdiť, nakoľko je filter funkčný a spoľahlivý. V ďalšom texte teda neberieme do úvahy triviálne prípady ako napríklad spomínanú kalkulačku, ale skôr prípady ktoré nie je možné riešiť tak jednoducho. Napríklad ak bol pre aplikáciu vyvinutý kvalitný filter, ktorý ale pred svojou činnosťou nedekóduje vstup, bol by výsledok nasledovný: aplikácia by sa vedela ubrániť jednoduchému útoku ako napríklad <script>alert("xss");</script>, no nemusela by už odolať sofistikovanejšiemu %3Cscript%3Ealert%28%22XSS%22%29%3B%3C%2Fscript%3E, v ktorom sú špeciálne znaky zakódované URL kódovaním. Ďalším problémom môže byť chybný predpoklad, že ak úplne zablokujeme niektoré špeciálne znaky, opäť napríklad " a ', takýto útok nebude možné vykonať. Útok ale vykonať možné bude, vyzeral by nasledovne: <script>alert(string.fromcharcode(88,83,83));</script>. Funkcia String.fromCharCode vytvorí z poskytnutých čísel reťazec tak, že ku každému číslu priradí znak s patričnou ASCII hodnotou. Teda vznikne ten istý kód ako predtým, ale bez nutnosti použitia úvodzoviek na vloženie reťazca. 23 Ich zoznam je dostupný na prípadne je možné ho vyčítať zo zdrojového kódu filtru. 24 Samozrejme len v danej situácii. 17

24 Tieto dva príklady boli z tých jednoduchších, v komplexných aplikáciách je situácia úplne iná, často je náročným problémom udržať prehľad v tom, ktoré vstupné dáta kam v aplikácii putujú, kde sa v akom kódovaní zobrazia prípadne ako je možné ich upraviť. Na tomto mieste by som chcel odkázať na kvalitný zdroj [6], v ktorom sú popísané mnohé techniky a metódy obchádzania filtrov. Mnohé z nich však vyžadujú pochopenie problematiky, nakoľko nefungujú za každých okolností. 18

25 Kapitola 6 Praktická časť V rámci tejto práce bola okrem teoretickej, textovej časti vypracovaná aj čas praktická. Táto praktická časť obsahuje malé ukážkové aplikácie, ktorých účelom je demonštrovať vybrané znalosti popísané v teoretickej časti. 6.1 Obsah praktickej časti Praktická časť pozostáva z piatich menších aplikácií. Prvé tri príklady znázorňujú scenáre útokov typu XSS proti jednoduchým aplikáciám, ďalší príklad ilustruje neefektívnu metódu obrany a posledný napokon obsahuje implementáciu funkčnej obrany proti útokom typu XSS. Nasleduje zoznam príkladov aj s popismi. Názov príkladu Kradnutie dát z formuláru Kradnutie cookies Poplašná správa - HOAX Necyklický filter Funkčná ochrana proti XSS Popis V tomto príklade je aplikácia, ktorá obsahuje prihlasovací formulár, a na tej istej stránke zobrazuje užívateľom zadávaný obsah - knihu návštev. Vložením útočného kódu ako príspevku do knihy návštev je možné zmanipulovať prihlasovací formulár tak, že vložené údaje pošle niekam inam. Táto aplikácia obsahuje vyhľadávací formulár. Text, ktorý je zadaný do vyhľadávania je následne znova zobrazený na stránke. Útok kradne užívateľom informácie zo súborov cookie. Aplikácia okamžite zahajuje PHP session, teda do súboru cookie ukladá obsah premennej phpssid - identifikátor relácie. Ak sa útočníkovi podarí túto informáciu získať, u mnohých aplikácií to znamená, že môže konať v kontexte daného užívateľa, ako keby bol za neho prihlásený. Tento útok je zameraný na podstrčenie poplašnej správe obeti útoku. Zraniteľným miestom aplikácie je vyhľadávanie, v tomto prípade je však výpis vyhľadávaného slova realizovaný pomocou Javascriptu. Tento útok teda patrí medzi útoky založené na DOM - v práci podkapitola Na útoku je zaujímavé ešte to, že vďaka použitiu fragmentu - "#" sa útočný kód nepošle na server. Táto ukážka je veľmi podobná účinnej ochrane, ale s jedným rozdielom. Implementovaný filter je upravený tak, že nie je cyklický, a teda ani účinný, aj keď na prvý pohľad by sa mohlo zdať, že účinný je. Tento problém je spomenutý v práci v podkapitole v časti "filtrovanie". Táto ukážka obsahuje funkčnú implementáciu filtru, ktorý ochraňuje aplikáciu pred útokmi XSS. Aplikácia je galéria obrázkov, ktoré je možné vkladať pomocou HTML prvku img. Podrobnejší popis aplikácie aj implementácie sa nachádza v práci v podkapitole 5.2.2, časť "Ukážka implementácie filtru v PHP". 19