Doc. Ing. Ladislav Hudec, CSc. Bezpečnosť webu Doc. Ing. Ladislav Hudec, CSc. 1

Koncepcia fungovania webu Začneme generickým opisom webu ako technickej infraštruktúry: Nebudeme si všímať mnohé detaily protokolov, formátov dát a softvérových komponentov realizujúcich všeobecné princípy. Tiež sa bude abstrahovať od špecifických chovaní jednotlivých prehliadačov. Aj keď prehliadače dostupné na trhu narábajú s mnohými situáciami rovnako, stále sú medzi nimi rozdiely. Navyše môžu v budúcnosti zmeniť režim fungovania ako reakciu na nové bezpečnostné výzvy. Výraz Web 1.0 je skratka na označenie webových aplikácií, ktoré doručujú statický obsah. Na obrázku je znázornený základný tok informácií pre takúto konfiguráciu. Na strane klienta je interakcia s aplikáciou zabezpečená prostredníctvom prehliadača Na strane servera webový server prijíma požiadavky klienta. Skripty webového servera vyberajú vstupy z dát poslaných klientom a vytvárajú žiadosti pre back-end server (napríklad databázový server). Webový server obdrží odpoveď (výsledok) od back-end servera a vráti klientovi výsledné HTML stránky (a dáta Cascading Style Sheets) ako odpoveď na klientovu žiadosť. webový server klient back-end HTML & CSS data žiadosti HTTP prehliadač 2

Transportný protokol a formáty dát Transportným protokolom na komunikáciu medzi klientom a serverom je HTTP (Hyper Text Transport Protocol): HTTP/1.1 je špecifikovaný v RFC2616 HTTP je umiestnený na aplikačnej vrstve protokolového zásobníka RM ISO/OSI. (Pozor nezamieňať sieťovú aplikačnú vrstvu s biznis aplikačnou vrstvou v softvérovom zásobníku!) Klient pošle žiadosť HTTP na server. Táto žiadosť stanovuje metódu, ktorá sa vykoná na zdroji servera. Metóda GET získa informáciu zo servera. Zdroj je zadaný prostredníctvom Request-URI (Universal Resource Identifier) a poľom hosta (host) v hlavičke žiadosti. Syntax URI je opísaná v RFC3986. Nech na lište prehliadača je zdroj zadaný takouto dvojicou host a URI www.wiley.com/WileyCDA/Section/id-302475.html?query=computer%20security Pole hosta je výraz po prvé lomítko z ľava (www.wiley.com), pole URI je za lomítkom (WileyCDA/Section/id-302475.html?query=computer%20security). Pole hosta sa číta z prava do ľava, pole URI sa číta z ľava do prava. Útoky môžu využívať túto zvláštnosť tak, že skonštruujú meno hosta obsahujúce znak podobajúci (interpretujúci) sa na lomítko. Používateľ parsujúci lištu prehliadača bude interpretovať reťazec od tohto podvodného znaku ako meno hosta. Na odstránenie takéhoto útoku vývojári prehliadačov používajú dve stratégie: Blokovanie nebezpečných znakov (ktoré je možné interpretovať ako lomítko). Tento prístup však nefunguje, ak takýto znak je dovoleným znakom v abecede, v ktorej je napísané meno hosta. Zobrazenie používateľovi, kde prehliadač rozdeľuje meno hosta od URI. Používateľova abstrakcia môže byť potom porovnávaná s implementáciou v prehliadači. 3

Transportný protokol a formáty dát Metóda POST špecifikuje zdroj v Request-URI a v tele žiadosti HTTP stanovuje akciu, ktorá sa na zdroji vykoná. Použitie metódy POST bolo zamýšľané na posielanie správ, okomentovaní zdrojov a posielanie dát veľkých objemov, ktoré by sa nevmestili do Request-URI. Samozrejme v podstate môže byť metóda POST použitá na každú inú akciu, ktorá môže byť vyžadovaná používaním metódy GET. Bočné efekty sa môžu odlišovať podľa toho, či bola akcia požadované metódou GET alebo POST. Server pošle klientovi odpoveď HTTP. Webové stránky v odpovediach HTTP sú napísané v jazyku HTML. Vo webovej stránke sa môžu nachádzať tieto elementy: Frame – Rámec (subwindow) Iframe – pripojené subwindow (in-lined subwindow) Img – vnorený obrázok (embedded image) Applet –Java applet Form – interaktívny element špecifikujúci akciu, ktorá bude vykonaná na zdroji. Spustí ju konkrétna udalosť. Kliknutie na ikonu je príkladom takejto udalosti. Server môže používať Cascading Style Sheets (CSS), ktoré dávajú ďalšie informácie ako zobraziť webovú stránku. 4

Webový prehliadač a model hrozby pre webové aplikácie Prehliadač klienta vykonáva niekoľko funkcií: Zobrazuje webové stránky. Prehliadač používa internú reprezentáciu webovej stránky, ktorej sa hovorí doménový objektový model DOM (Domain Object Model). Túto konkrétnu reprezentáciu vyžaduje JavaScript. Spravuje relácie. Vykonáva riadenie prístupu pre skripty, ktoré sú vykonávané v rámci webovej stránky. Keď prehliadač obdrží HTML stránku, tak parsuje HTML a pre DOM vytvorí document.body. Objekty ako document.URL, document.location a document.referrer získajú svoje hodnoty podľa toho ako prehliadač vidí aktuálnu stránku. Model hrozieb pre webové aplikácie je založený na škodlivom koncovom systéme. Tento útočník vidí iba správy, ktoré sú mu adresované a údaje získané z kompromitovaných koncových systémov prístupných prostredníctvom prehliadača. Útočník tiež vie uhádnuť predpovedateľné polia v správach, ktoré nevidí. Komunikačná sieť je bezpečná. Koncové systémy môžu byť škodlivé alebo môžu byť kompromitované prostredníctvom prehliadača. Neuvažujeme útoky využívajúce slabiny v implementácii iných sieťových protokolov. 5

Autentizované relácie Od verzie protokolu HTTP/1.1 boli klient a server schopní zriadiť komunikačnú reláciu nad TCP: Takéto relácie nie sú autentizované. Ak zdroje aplikácie podliehajú riadeniu prístupu, musí byť používateľ na strane klienta autentizovaný ako pôvodca žiadosti. Toto je možné dosiahnuť zriadením autentizovanej relácie. Autentizované relácia existuje na troch konceptuálnych vrstvách: Na biznis aplikačnej vrstve – ako vzťah medzi používateľom a poskytovateľom služby Na sieťovej aplikačnej vrstve – medzi prehliadačom a webovým serverom Na transportnej vrstve – medzi klientom a serverom Autentizované relácie na transportnej vrstve môžu byť zriadené protokolom SSL/TLS. Ak používateľ a webový server vlastnia certifikáty, potom protokol TLS zabezpečuje vzájomnú autentizáciu. Ak používateľ a poskytovateľ služby zdieľajú heslo, je možné vzájomnú autentizácia zabezpečiť napríklad aj protokolom EAP-TTLS (EAP Tunnelled TLS). Autentizované relácie na biznis aplikačnej vrstve môže server poslať klientovi autentizátor. Autentizátor musí byť uložený v privátnom priestore aplikácie na strane klienta. V JavaScripte skript bežiaci v prehliadači môže na tento účel použiť privátny objekt. 6

Autentizované relácie Na sieťovej aplikačnej vrstve môže server vytvoriť identifikátor relácie SID (Session IDentifier) a poslať ho klientovi. Iba pripomíname, že v našom modele hrozieb môže SID byť odchytený iba keď je uložený na koncovom systéme (a nie pri prenose medzi serverom a klientom). Klient vkladá SID do následných žiadostí na server. Žiadosti sú autentizované ako patriace do relácie ak obsahujú správny SID. Server mohol autentizovať používateľa predtým ako mu vydal SID, tento fakt môže zakódovať do SID. Na druhej strane server mohol používateľovi vydať SID bez predchádzajúcej autentizácie používateľa a SID môže použiť na kontrolu, že žiadosti patria tej istej relácii. Existujú tri metódy na prenášanie SID: Cookie – poslané serverom v odpovedi HTTP v poli hlavičky Set-cookie (RFC2965). Prehliadač uloží cookie v document.cookie a vkladá ho do žiadostí pre doménu pôvodu cookie. Dopytovací reťazec URI (URI query string) – SID je vkladané do Request-URI pre zdroje aplikácie Parameter POST – SID je uložený v skrytom poli vo formulári HTML. V prípade, že SID sa používa na riadenie prístupu, musí sa brať do úvahy, že škodlivý klienti a vonkajší útočníci sa môžu pokúsiť modifikáciou SID (cookie) zvýšiť svoje prístupové práva. Takýmto útokom sa hovorí otrávenie cookies (cookie poisoning). Vonkajší útočník môže ďalej skúšať kvalifikovane odhadnúť klientove cookie, napríklad po útočníkovom predchádzajúcom kontaktovaní servera, a skúsiť využiť svoj odhad na impersonifikáciu používateľa. Útočník sa môže pokúsiť ukradnúť cookie klientovi alebo serveru. Model hrozby webu kladie na SID dve požiadavky: musí byť nepredpokladateľný a musí byť uložený na bezpečnom mieste. Server môže zabrániť modifikácii SID tak, že k SID pripojí autentizačný kód správy MAC (SID spojí s tajomstvom servera a vypočíta hašovaciu hodnotu). 7

Zaistenie rovnakých koncov komunikácie Na nasledujúcom obrázku je ilustrované používanie protokolu EAP-TTLS (EAP Tunneled TLS) tak ako sa používa dnes. EAP-TTLS sa používa v prípade, keď používateľ sa pripája k serveru z klientskeho stroja. Server má certifikát. Klient využije TTLS na autentizáciu servera a zriadenie bezpečného tunela medzi prehliadačom na klientskom stroji a serverom. Používateľ je autentizovaný na serveri heslom, napríklad protokolom CHAP (RFC1994). Protokol EAP-TTLSv0 je špecifikovaný v RFC5281 a podporuje vnútorné dedičné metódy (ako napríklad CHAP). Väčšina výpočtovo náročných úloh sa vykonáva na serveri. V prvom kole výmen EAP protokol TLS beží s jednostrannou autentizáciou servera (kroky 3 až 6). Počnúc krokom 7 sú správy posielané cez bezpečný TLS tunel. V záverečnom kole protokolu EAP (kroky 7 a 8) sa vykoná autentizácia používateľa pomocou hesla. EAP-TTLS chráni pred útokom man in the middle za predpokladu, že TLS tunel bol zriadený so zamýšľaným serverom. Vyššie uvedený scenár je bezpečný pokiaľ obe relácie majú ten istý koniec. V prípade, že používateľ sa nechá oklamať a otvorí reláciu TLS s útočníkom, môže sa realizovať útok man in the middle. Na ďalšom obrázku je ilustrovaný takýto útok. 8

Zaistenie rovnakých koncov komunikácie EAP tunelované TLS: EAP-TTLSv0 s CHAP autentizáciou používateľ/ klient webový server (change cipher specification, finished) Server Hello, certificate, server key exchange, Server Hello done bezpečný tunel 7. EAP-Request/EAP-TTLS 8. EAP-Response/EAP-TTLS 9. EAP-Success/EAP-Failure ([User Name], [CHAP-Challenge], [CHAP-Password]) 1. EAP-Request/Identity 2. EAP-Response/Identity (id) 3. EAP-Request/EAP-TTLS (start) 4. EAP-Response/EAP-TTLS (Client Hello) 5. EAP-Request/EAP-TTLS 6. EAP-Response/EAP-TTLS client key exchange, change cipher specification, finished 9

Zaistenie rovnakých koncov komunikácie Útok man in the middle: Používateľ otvorí tunel TLS k útočníkovi a útočník otvorí tunel TLS k serveru. Server požiada o autentizačné doklady (heslo) používateľa. Útočník prepošle túto žiadosť používateľovi. Používateľ odpovie poslaním hesla útočníkovi cez bezpečný kanál. Útočník úspešne dokončí autentizáciu používateľa na serveri. Server vytvorí používateľský autentizátor UAC (User AuthentiCator), napríklad cookie, a pošle ho používateľovi prostredníctvom útočníka. Teraz útočník môže impersonifikovať používateľa. Ochrana pred takýmto útokom spočíva v tom, že UAC nemôžu byť zviazané iba s autentizačnými dokladmi používateľa, ale aj s reláciou TLS, cez ktorú sú autentizačné doklady prenášané na server. Takto môže server detekovať či požiadavka je poslaná a prijatá tou istou reláciou. Pokiaľ sú relácie rôzne, potom pravdepodobne medzi klientom a serverom sedí man in the middle. Tento útok kombinuje dva tunely TLS v priestore. webový server klient man in-the-middle UAC TLS tunel prehliadač 10

Zaistenie rovnakých koncov komunikácie Útok man in the middle môže kombinovať dva tunely TLS v čase (viď obrázok): Tento útok využíva slabinu v spôsobe ako webový server používa TLS na autentizáciu používateľa. Používateľ najprv zriadi anonymný tunel TLS na server. Autentizácia používateľa je spustená až vtedy, keď používateľ žiada prístup ku chránenému zdroju. V takomto prípade server pošle správu TLS Hello Request, ktorou vyzve používateľa opätovne dohodnúť reláciu TLS. V novej relácii je používateľ autentizovaný prostredníctvom PKI. Špecifikácia TLS nestanovuje žiadne požiadavky na spojenie medzi týmito dvomi reláciami (existujúca a novo dohadovaná), ale webový server predpokladá, že opätovná dohoda začína v tuneli TLS a vedie pozdĺž tohto tunela. Tento predpoklad je konzistentný so starým modelom hrozieb, ktorý vychádzal z toho, že konce komunikácie sú dôveryhodné a nedôveryhodné je sieťové prostredie. Tento predpoklad samozrejme nie je kompatibilný s webovými nepriateľmi. Keď sa totiž opäť dohaduje tunel so škodlivým koncovým bodom, potom nový tunel môže končiť niekde inde. Útok je spustený škodlivým koncovým bodom (útočníkom). Keď obeť štartuje reláciu TLS, útočník pozdrží iniciálnu správu Client Hello a sám si so serverom dohodne anonymnú reláciu TLS. Potom útočník vykoná akciu vyžadujúcu autentizáciu používateľa, napríklad niečo pošle na zdroj na server. Teraz server pošle útočníkovi správu TLS Hello Request, útočník odpovie pozdržanou správou Client Hello a ďalej pošle obeti žiadosť servera o certifikát. Obeť pošle svoje autentizačné doklady, čím sa vytvorí obojstranne autentizovaný tunel. Ak útočníkova „visiaca“ žiadosť HTTP (na základe ktorej sa vyvolala renegociácia relácie) je nejako pripojená k prvej žiadosti v novom tuneli (v protokole HTTP existuje spôsob ovplyvnenia ako bude spracovaný nasledujúca hlavička HTTP), potom bude vykonaná s oprávneniami obeti. V dôsledku tohto útoku bola upravená špecifikácia TLS pre renegociáciu (RFC5746). 11

Zaistenie rovnakých koncov komunikácie Útok man in the middle využívajúci opakovane dohadovanú relácie TLS používateľ/ klient man in-the-middle webový server Client Hello Server Hello, certificate, done key exchange, cipher specification, finished anonymný tunel na server change cipher specification, finished POST/target/evil.html HTTP/1.1 Hello Request Server Hello, certificate, certificate request, done certificate, key exchange, cert verify, change cipher specification, finished vzájomne autentizovaný tunel change cipher specification, finished, HTTP/1.1 ok GET/target HTTP/1.1 12

Politiky pôvodu kódu Cieľom politiky pôvodu kódu, ktorú presadzujú webové prehliadače, je ochrániť obsah aplikácie a identifikátory relácie pred vonkajšími útočníkmi. Webová aplikácia je identifikovaná podľa domény, v ktorej hosťuje webový server. Politika pôvodu kódu určuje, že: skripty sa smú pripájať späť iba k doméne, z ktorej pochádzajú cookies sú vložené iba do žiadostí do tých domén, ktoré ich vydali. Dva URL (Uniform Resource Locator) majú rovnaký pôvod, ak zdieľajú rovnaký protokol, meno hosta a číslo portu. V nasledujúcej tabuľke je dokumentovaná táto politika pri posúdení rovnakého pôvodu pre http://www.my.org/dir1/hello.html. Táto politika neobmedzuje statický obsah HTML. Je možné do webovej stránky vnoriť obrázky z inej domény. URL Výsledok Dôvod http://www.my.org/dir1/some.html áno http://www.my.org/dir2/sub/another.html https://www.my.org/dir2/some.html nie Iný protokol http://www.my.org:81/dir2/some.html Iný port http://host.my.org/dir2/some.html Iný host 13

Politiky pôvodu kódu Politika rovnakého pôvodu je príliš reštriktívna v prípade, že je potrebná komunikácia medzi hostmi v rámci tej istej domény. Z toho dôvodu je veľmi častou výnimkou v politike rovnakého pôvodu možnosť komunikovať s hostami naprieč rodičovskej domény (parent domain traversal). Meno domény v DOM obsahuje súbor document.domain a toto meno je skrátené na časť .domain.tld. To znamená, že doména www.my.org bude v document.domain skrátené na my.org (ale nie na .org). Táto výnimka môže mať neželateľné bočné efekty v prípade, že DNS sa používa „kreatívne“. Napríklad doménové mená akademických inštitúcií v UK končia s .ac.uk, ale ac.uk nie je vhodnou doménou najvyššej úrovni. Ak prehliadač obmedzí prístup iba na časť domain.tld mena hosta, potom potenciálne ponechá otvorenú celú doménu ac.uk ako výnimku z politiky rovnakého pôvodu. Preto prehliadače prichádzajú so zoznamom výnimiek pre túto výnimku, t.j. kde sa nesmie vykonávať výnimka komunikácie naprieč rodičovskej doméne. Politiky založené na pôvode sú vo všeobecnosti dôležité pre servisne orientované architektúry (SOA). SOA je architektonická paradigma na využívanie distribuovaných schopností (služieb), ktoré môžu byť riadené rôznymi vlastníkmi. Bezpečnostné politiky regulujú spôsob ako služby môžu interagovať. Tieto politiky sa odvolávajú na služby. To znamená, že služby sa stávajú subjektmi (používateľmi) v riadení prístupu v SOA. A preto sa musí nájsť spôsob pomenovania týchto subjektov. Pre služby poskytované na webe sa stalo bežné používať DNS meno servera hostujúceho službu. Tu treba ale pripomenúť, že DNS nebolo navrhnuté na účel poskytnutia dôkazu na rozhodovanie o riadení prístupu. Služby komunikujú prostredníctvom správ. Keď služby sú subjekty a subjekty sú známe podľa mien hostov, bezpečnostné politiky zodpovedajú menám hostov. Keď sa presadzujú takéto bezpečnostné politiky, potom musí byť pôvod správ autentizovaný. 14

Politiky pôvodu kódu HTTP Referer – webové stránky môžu obsahovať žiadosti z rôznych domén. Pole Referer v hlavičke žiadosti (request-header) HTTP je určené dať klientovi spôsob špecifikácie zdroja URI, z ktorého bola získaná žiadosť. Avšak pole Referer nie je vždy prítomné a môže byť sfalšované. Preto sa riadenie prístupu nemôže naň spoliehať. 15

Cross-site scripting Cross-site scripting (XSS) je útok na zvyšovanie privilégií, ktorý zneužíva klientovu „dôveru“ v server. Webové stránky z dôveryhodného servera sú spracované v kontexte, ktorý má viac oprávnení než oprávnenia, ktoré by mohla získať stránka z útočníkovho servera. Napríklad, dôveryhodný server môže byť na intranete a útočníkov server na internete. Útok posunie klientovi skript cez dôveryhodný server, čím sa vyhne klientovej bezpečnostnej politike založenej na pôvode. Používateľ musí byť nalákaný na vykonanie akcie, ktorá spustí útok, t.j. na kliknutie na otrávenú linku. Na nasledujúcom obrázku je príklad slabiny odrazený (reflected) XSS s ukradnutím cookie. V prípade odrazeného XSS je skript uložený v stránke na útočníkovom serveri a obeť musí byť nalákaná ísť najprv na túto stránku. Akcia používateľa potom pošle skript na dôveryhodný server, ktorý musí echovať späť klientov vstup (skript), aby sa tento skript vykonal na klientovi. Napríklad, útočník si pripravil stránku obsahujúcu takýto element: <A> HREF=„http://trusted.com/comment.cgi? mycomment=<SCRIPT alert(´You have a XSS problem´) ></SCRIPT>“> Click here </A> V prípade, že obeť klikne na linku k tomuto elementu na útočníkovej stránke, URL poslané na trusted.com obsahuje skript v mycomment. Ak dôveryhodný server echuje vo výslednej stránke hodnotu mycomment, potom sa skript na klientovi vykoná v rámci stránky z dôveryhodného servera. V našom prípade bude používateľ upozornený na slabinu XSS. 16

Cross-site scripting dôveryhodný server prehliadač klient Typickým príkladom aplikácií echujúcich klientov vstup sú vyhľadávajúce stroje (search engines) alebo obyčajné stránky 404 (not found). Existuje veľa spôsobov na vnorenie skriptu. Napríklad, skript môže byť vybratý z útočníkovho sídla cez element obrázku: mycomment= <IMG SRC=´http://attacker.org/badfile´ ></IMG>“> dôveryhodný server klient útočníkov server prehliadač 4. cookie 1. klik na stránku 2. Interaktívny element s vnoreným skriptom 3. výsledná stránka s vnoreným skriptom 17

Cross-site scripting V uloženom (stored) XSS útoku útočník umiestni skript priamo na dôveryhodný server. Aplikácie bulletin board sú vhodní kandidáti na uložený XSS. Keď obeť navštívi položku útočníkovho bulletin board, skript vnorený do položky sa vykoná na strane klienta. V útoku XSS založenom na DOM útočník injektuje skript do DOM cez objekt document. Vektor útoku sa rozdelí na dve časti. Škodlivý skript je vnorený do URL webovej stránky útočníka. Táto stránka obsahuje tiež linku na stránku na dôveryhodnom serveri, ktorý referencuje URL v DOM v čase jeho naplnenia prehliadačom. Keď je obeť nalákaná na návštevu útočníkovej webovej stránky, prehliadač uloží zlé URL do document.URL a požiada o webovú stránku z dôveryhodného servera. Keď prehliadač zavedie webovú stránku, bude referencovaný document.URL a vykoná sa útočníkov skript. Kradnutie cookies. Prehliadač uloží cookies do súboru document.cookie. Cookies podliehajú politike rovnakého pôvodu a sú pripájané iba do žiadostí do domény, ktorá cookie vydala. V prípade odrazeného XSS útoku môže vykonávajúci sa útočníkov skript na klientovi čítať z document.cookie klientove cookie pre dôveryhodný server a môže poslať ich hodnotu späť útočníkovi. Táto aktivita neporušuje politiku rovnakého pôvodu, pretože skript sa vykonáva v kontexte útočníkovej webovej stránky. 18

Cross-site scripting Ochrana proti XSS. Prehliadač zlyháva pri presadzovaní svojej politiky rovnakého pôvodu kódu, pretože prehliadač môže kontrolovať iba pôvod natiahnutej webovej stránky a nie skutočný pôvod všetkých elementov v rámci stránky. Napríklad, prehliadač autentizuje službu bulletin boardu ale nie používateľa, ktorý tam uložil túto konkrétnu položku. Ak prehliadač nie je schopný autentizovať pôvod všetkých svojich vstupov , nie je schopný presadzovať politiku pôvodu kódu. Ochranu proti útokom XSS možno rozdeliť do troch kategórií: Považovať XSS za útok injekcia kódu. Kódovanie výstupov servera, filtrovanie vstupov klienta. Klient môže napríklad porovnávať žiadosti a odpovede s cieľom kontrolovať či podozrivo veľká časť žiadosti nebola skopírovaná do odpovedi. Zmeniť modus operandi prehliadača. Zablokovať vykonávanie skriptov v prehliadači. Zlepšiť autentizáciu alebo použiť na riadenie prístupu iba atribúty, ktoré môžu byť autentizované. Je možné chrániť cookie pomocou bezpečnostnej politiky prehliadača, napríklad zaradiť navštívené webové stránky do zóny, ktorá nemá oprávnenie pristupovať k súboru document.cookie. Je možné vzdať sa používania cookies na vytváranie relácií a používať iné mechanizmy na autentizáciu klientových žiadostí. Napríklad nepredpovedateľné jednorázové URL poslané serverom klientovi počas používateľovej autentizácie môže autentizovať žiadosti ako priamo prichádzajúce od klienta. 19

Cross-site request forgery Cross-site request forgery útok (XSRF), tiež niekedy cross-site reference forgery, vykonáva akcie na cieľovom webovom sídle s privilégiami „dôveryhodného“ používateľa. V tomto prípade „dôveryhodný“ znamená autentizovaná relácia medzi klientom a serverom. Nezávisí od toho akým spôsobom bola relácia zriadená, či prostredníctvom TLS, autentizácia heslom HTTP alebo iným spôsobom. Je dôležité, aby žiadosti v tejto relácii boli vykonávané s bezpečnostnými oprávneniami pridelenými klientovi. V odrazenom (reflected) XSRF útoku musí používateľ navštíviť útočníkovú webovú stránku, ktorá obsahuje skryté akcie na cieľové sídlo, napríklad v interaktívnom elemente HTML. Súčasne musí mať klient zriadenú aktívnu reláciu na cieľové sídlo. Keď používateľ navštívi útočníkovu stránku, prehliadač automaticky pošle dáta interaktívneho elementu na cieľové sídlo. Cieľové sídlo interpretuje žiadosť ako prichádzajúcu od klienta a serverom je akceptovaná akcia žiadaná v interaktívnom elemente ako prichádzajúca od autentizovaného používateľa. Takýmto spôsobom sa XSRF vyhne bezpečnostnej politike cieľového sídla založenej na pôvode. 20

Cross-site request forgery V uloženom (stored) XSRF útoku je škodlivá stránka uložená na dôveryhodnom serveri (viď obrázok). Keď klient navštívi túto škodlivú stránku, klientov prehliadač bude nasmerovaný späť na server a akcie vložené útočníkom sa budú vykonávať ako prichádzajúce od klienta. Uložené XSFR útoky majú dobrú šancu na úspech, pretože klient požadujúci škodlivý obsah je pravdepodobne autentizovaný a autorizovaný vykonať tieto akcie. dôveryhodný server klient Útočníkov server prehliadač 2. klik na linku v stránke 3. škodlivá akcia presmerovaná na cieľové sídlo autentizovaný tunel 1. stránka s vnoreným linkom na cieľové sídlo 21

Cross-site request forgery Pri útoku XSRF zlyháva cieľové sídlo pri presadzovaní svojej politiky pôvodu kódu, pretože cieľové sídlo je schopné autentizovať iba posledný krok žiadosti, a nie nevyhnutne skutočný pôvod žiadosti. Na ochranu proti XSRF musia byť žiadosti vhodne autentizované. Na autentizáciu je potrebné zdieľané tajomstvo medzi klientom a serverom. Toto (dočasné) tajomstvo môže byť poslané (aj v otvorenej podobe) zo servera klientovi pri zriadení relácie. V uvedenom modeli webových útokov nemôže byť tajomstvo kompromitované pri prenose, ale iba v koncových systémoch. Je preto podstatné, aby tajomstvo bolo uložené na lokácii, ktorá nie je dostupná vykonávajúcim sa skriptom v prehliadači. Ak je stránka zraniteľná na XSS, potom to môže byť spôsobené kompromitáciou autentizácie. Na autentizáciu žiadosti klient skonštruuje autentizátor odvodený z tajomstva. Autentizátor by mal byť nepredvídateľný identifikátor relácie použitý pri každej akcii v relácii, iné akcie by mali mať individuálne autentizátory alebo autentizátor by mohol byť autentizačný kód správy (Message Authentication Code) ako XSRFPreventionToken = HMAC(Action_Name+Secret.SessionID) Prehliadač posiela autentizátor s akciou. V žiadosti GET je autentizátor vložený ako token v URI (tiež známe ako „prepísanie URI“ – URI rewriting). V žiadosti POST je autentizátor poslaný v skrytom poli formulára. Server autentizuje každú žiadosť o akciu ešte pred jej vykonaním. Útočník, ktorý nepozná tajomstvo nie je schopný vytvoriť legitímnu žiadosť o akciu. Žiadosti o akciu sú teraz autentizované na úrovni webovej aplikácii, t.j. na úrovni „nad“ prehliadačom. Cookies nie sú vhodné na uloženie a prenos autentizátora, pretože sa posielajú prehliadačom automaticky a môžu byť uložené dlhšie než je trvanie relácie. 22

Cross-site request forgery Proxy umiestnené medzi prehliadačom a sieťou môže implementovať ochranu na strane klienta pre relácie sieťovo aplikačnej vrstvy (nie pre TLS relácie!). Táto ochrana sa vykoná autentizáciou pôvodu lokálnych žiadostí. Proxy označuje všetky URL v prichádzajúcich webových stránkach nepredvídateľným tokenom a udržuje databázu s asociáciou tokenov s doménami. Proxy tiež kontroluje všetky odchádzajúce žiadosti na prítomnosť tokenu: Ak nie je nájdený žiadny token, potom je žiadosť generovaná lokálne a môže byť poslaná v autentizovanej relácii. Ak token je nájdený a pôvod žiadosti odpovedá doméne, potom je žiadosť poslaná. Žiadosť je povolená podľa politiky rovnakého pôvodu a môže byť poslaná v autentizovanej relácii. V ostatných prípadoch všetky autentizátory (SID, cookies) doplnené prehliadačom sú pred poslatím žiadosti z URI odstránené. Autentizácia pre dôveru. Pri útokoch na autentizačné protokoly sa doposiaľ musí útočník vždy pokúšať o impersonifikáciu niekoho. Tieto útoky nesprávne prideľujú zodpovednosť (účtovateľnosť). Obeť (impersonifikovaný používateľ) je vzatá na zodpovednosť za útočníkove akcie. Avšak existujú aj útoky, v ktorých obeť impersonifikuje útočníka, t.j. akcie obete sú pripísané útočníkovi. Napríklad, útočník sa môže stať vlastníkom ľubovoľných súborov vytvorených obeťou a môže neskoršie kontrolovať, čo bolo do nich zapísané. Sú rozdiely medzi autentizáciou pre zodpovednosť a autentizáciou pre dôveru. 23

Cross-site request forgery Login XSRF útok je príkladom útoku na autentizáciu pre dôveru. Stránka pripravená útočníkom obsahuje interaktívny element, ktorý naloguje útočníka na cieľové webové sídlo. Keď obeť navštívi útočníkovú stránku a spustí akciu cez interaktívny element, cieľový server prostredníctvom prehliadača obete obdrží útočníkové autentizačné dáta a cieľový server pripíše útočníkovi každý vstup, ktorý vloží obeť do otvorenej stránky. dôveryhodný server klient útočníkov server prehliadač 4. vstup používateľa prisúdený útočníkovi 1. klik na stránku 2. Stránka s útočníkovým interaktívnym elementom na login na serveri 3. výsledná stránka 24

Unesenie Javascriptu Technológie Web 2.0 kombinujú črty podporujúce vytváranie nových typov webových aplikácií. Tieto črty môžu byť tiež zdrojom nových zraniteľností. AJAX (Asynchronous JavaScript and XML) podporuje asynchrónne interakcie medzi klientom a webovým serverom. Prehliadač posiela žiadosti JavaScript enginu AJAX, ktorý zabezpečuje komunikáciu medzi klientom a serverom (viď obrázok) JSON (JavaScript Object Notation) je formát na prenos dát. Reťazce JSON sú serializované objektom JavaScript, vrátené späť do objektu v engine AJAX volaním eval() a s reťazcom JSON ako argumentom. Objekt je vytvorený pomocou JavaScript konštruktora objektov. Webový server môže dynamicky aktualizovať informácie na strane klienta. Toto je užitočná črta na automatizáciu noviniek softvérových aktualizácií. Webový server môže manipulovať klientov DOM cez príznaky dynamických skriptov a môže zrušiť (override) konštruktory JavaScript stránok klienta. webový server klient back-end HTML & CSS data žiadosti HTTP prehliadač XML, JSON AJAX JavaScript 25

Unesenie Javascriptu Uvedené črty môžu byť zneužité na rozšírenie útoku XSRF a zverejnenie útočníkovi dôverných údajov zo servera. Prvá fáza útoku unesenia Javascriptov sleduje vzor útoku XSRF. Používateľ musí navštíviť útočníkovu webovú stránku a súčasne má autentizovanú reláciu s cieľovým serverom. Útočníkova stránka obsahuje skript, ktorý redefinuje konštruktor Javascriptu v klientovom prehliadači (krok 1a na obrázku) a skript v žiadosti na cieľový server. Žiadosť požaduje dôverné dáta, ku ktorým je používateľ autorizovaný pristúpiť. Keď používateľ klikne na linku v útočníkovej stránke, prehliadač pošle žiadosť so súčasnými parametrami klientovej relácie na cieľové sídlo, t.j. klientove cookie (krok 1b). Táto žiadosť bude autentizovaná ako prichádzajúca od oprávneného používateľa a dôverné údaje budú poslané klientovi (krok 2). cieľový server klient útočníkov server prehliadač 1a. konštruktor 3. dôverné údaje 1b. formulár so žiadosťou o dôverné údaje 2. výsledná stránka s dôvernými údajmi 26

Unesenie Javascriptu Druhá fáza útoku vyberie dôverné údaje od klienta. Útočníkov skript má prednosť pred natívnym konštruktorom objektov Javascript v prehliadači. JSON prichádzajúci vo výslednej stránke od cieľového sídla je spracovaná enginom AJAX. Modifikovaný konštruktor vytvorí objekt Javascript, zachytí dôverné údaje a pošle ich späť útočníkovi (krok 3). Tento krok je vykonaný v kontexte webovej stránky útočníka a tak poslanie dôverných dát útočníkovi je legálne. Obrana proti prvej fáze útoku je rovnaká ako pri XSRF. Obrana proti druhej fáze útoku je zmena modus operandi klienta. Server modifikuje svoju odpoveď JSON, čo znamená, že nemôže byť vykonaná priamo prehliadačom, ale musí byť najprv spracovaná žiadajúcou aplikáciou. Napríklad, každá odpoveď JSON by mala byť prefixovaná príkazom while (1), ktorý spôsobuje nekonečnú slučku. Aplikácia musí odstrániť tento prefix predtým než môže byť vykonaný akýkoľvek Javascript v odpovedi. Alternatívne, odpoveď JSON by mohla byť poslaná ako komentár (comment). Aplikácia musí najprv odkomentovať prijatú JSON odpoveď. V obidvoch prípadoch musí byť Javascript v odpovedi vykonaný na klientovi v kontexte aplikácie. Škodlivá webová stránka nemôže odstrániť blok. 27

Unesenie Javascriptu Výhľad do budúcnosti. Model vykonávania webu sa stále vyvíja a dôležité bezpečnostné aspekty sa môžu rapídne meniť. Web verzie 2.0 venuje pozornosť koncepcii mashups, čo sú webové aplikácie kombinujúce obsah z viacerých sídiel. Riadenie prístupu v takomto prípade sa musí posunúť nad rámec politiky rovnakého pôvodu a musí byť možnosť špecifikácie ako môžu aplikácie interagovať. Na presadzovanie takýchto politík musí byť možnosť autentizovať služby. Autentizácia by mohla: Verifikovať meno služby. Rozpoznať, či je to tá istá strana ako naposledy. Toto je veľmi užitočná vlastnosť podporujúca induktívny bezpečnostný argument: ak si bol na správnom sídle po prvý krát, vždy sa vrátiš na správne sídlo. Zaregistrovať materiál, ktorý na tvoj počítač podstrčil niekto iný. Skontrolovať, či strana na druhom konci je človek a nie bot. Na tento účel sa aplikujú vizuálne puzzle CAPTCHA (Completely Automated Public Turing test to tell Computers and Human Apart). 28