1 Západočeská univerzita v Plzni Fakulta aplikovaných věd Katedra informatiky a výpočetní techniky Diplomová práce Systém oprávnění v EEG/ERP portálu ...
Za´padoˇceska´ univerzita v Plzni Fakulta aplikovany´ch vˇed Katedra informatiky a vy´poˇcetn´ı techniky
Diplomov´ a pr´ ace Syst´ em opr´ avnˇ en´ı v EEG/ERP port´ alu
Plzeˇ n, 2011
Jiˇr´ı Vlaˇsimsk´ y
Prohl´ aˇ sen´ı Prohlaˇsuji, ˇze jsem diplomovou pr´aci vypracoval samostatnˇe a v´ yhradnˇe s pouˇzit´ım citovan´ ych pramen˚ u. V Plzni dne 18. kvˇetna 2011 Jiˇr´ı Vlaˇsimsk´ y
Abstract This diploma thesis deals with security and legal analysis of the EEG/ERP Portal web application which is used to store neuroinformatic data. It also provides multiple additional features like content-management system of EEG experiments, articles, measuring scenarios, system of user roles etc. As a part of this thesis is the analysis of neuroinformatic data storage legal aspects and subsequent access control to them. The next part of this work is focused to technical and security analysis of authentication and authorisation used in the current application which leads to better uderstanding of those aspects and identification of security weaknesses. The last part of this thesis describes implementation of new mechanisms and repairment of current ones. Better security for all data and more secure access to the whole application of EEG/ERP Portal is ensured.
A Podm´ınky u ´ˇ casti v projektu s n´ azvem Mˇ eˇ ren´ı mozkov´ e ” tivity“ A.1 Popis projektu . . . . . . . . . . . . . . . . . . . . . . . . . A.2 Pr˚ ubˇeh mˇeˇren´ı . . . . . . . . . . . . . . . . . . . . . . . . A.3 Podm´ınky u ´ˇcasti v projektu . . . . . . . . . . . . . . . . . A.4 Prohl´aˇsen´ı . . . . . . . . . . . . . . . . . . . . . . . . . . . A.5 Souhlas se zpracov´an´ım osobn´ıch u ´daj˚ u . . . . . . . . . . . B EEG Metadata B.1 Informace o mˇeˇren´e osobˇe B.2 Informace o mˇeˇr´ıc´ı osobˇe . B.3 Podm´ınky mˇeˇren´ı . . . . . B.4 Informace o sc´en´aˇri . . . .
34 36 37 37 38 38 39 39
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
ak. . . . .
. . . . .
56 56 56 57 58 58
. . . .
. . . .
59 59 59 59 60 61
´ 1 Uvod EEG/ERP port´al je webov´a aplikace slouˇz´ıc´ı ke spr´avˇe neuroinformatick´ ych dat z´ıskan´ ych mˇeˇren´ım mozkov´e aktivity. Tato aplikace tak´e poskytuje nˇekter´e dalˇs´ı funkcionality jako napˇr. redakˇcn´ı syst´em, administraci EEG experiment˚ u, sc´en´aˇr˚ u mˇeˇren´ı, uˇzivatel˚ u atd., ke kter´ ym je potˇreba zajistit pˇr´ıstup s dostateˇcnou u ´rovn´ı zabezpeˇcen´ı. C´ılem t´eto pr´ace byla anal´ yza pr´avn´ıch aspekt˚ u ukl´ad´an´ı neuroinformaˇ e republiky. tick´ ych dat v EEG/ERP port´alu s ohledem na legislativu Cesk´ Pˇri zpracov´an´ı dat jsou ukl´ad´ana tak´e osobn´ı data, kter´a jsou z´akonem klasifikov´ana jako citliv´a, proto je nutn´e, aby dokumenty, kter´e mˇeˇren´a osoba podepisuje odpov´ıdaly tˇemto z´akon˚ um a obsahovaly pˇredepsan´e n´aleˇzitosti. V pr´aci je tomuto probl´emu vˇenov´ana kapitola 3. D´ale je v dokumentu zm´ınˇeno, jak´e jsou souˇcasn´e trendy pˇri ˇreˇsen´ı autentizace a autorizace u webov´ ych aplikac´ı. Zejm´ena se pak jedn´a o vyuˇzit´ı modern´ıch autentizaˇcn´ıch mechanism˚ u jako jsou OAuth a OpenID, kter´e vyuˇz´ıv´a mnoho velk´ ych internetov´ ych port´al˚ u. V dokumentu je pops´ano jak´e v´ yhody tato ˇreˇsen´ı pˇrin´aˇs´ı a zda jsou vhodn´e pro vyuˇzit´ı v aplikaci. Bezpeˇcnost EEG/ERP port´alu je kv˚ uli charakteru uchov´avan´ ych dat velmi d˚ uleˇzit´a. V pr´aci je pops´ano souˇcasn´e ˇreˇsen´ı autentizaˇcn´ıch a autorizaˇcn´ıch mechanism˚ u, jejichˇz anal´ yza a testov´an´ı byly provedeny podle ˇzebˇr´ıˇcku deseti nejrozˇs´ıˇrenˇejˇs´ıch bezpeˇcnostn´ıch rizik roku 2010, sestaven´emu organizac´ı OWASP Foundation. Jelikoˇz v´ yvoj aplikace byl zapoˇcat pˇred nˇekolika lety, kdy nebylo na internetu bˇeˇzn´e vyuˇzit´ı extern´ıch autentizaˇcn´ıch poskytovatel˚ u, je v dokumentu pops´ano jak´ ym zp˚ usobem byly tyto mechanismy implementov´any, jak bylo rozˇs´ıˇreno st´avaj´ıc´ı ˇreˇsen´ı a opraveny nalezen´e nedostatky. Po pˇreˇcten´ı pr´ace z´ısk´a ˇcten´aˇr pˇredstavu nejen o tom, jak´e jsou pr´avn´ı aspekty uchov´av´an´ı neuroinformatick´ ych dat, ale i jak´ ym zp˚ usobem byly analyzov´any a rozˇs´ıˇreny souˇcasn´e autentizaˇcn´ı a autorizaˇcn´ı mechanismy spoleˇcnˇe s jejich d˚ usledn´ ym otestov´an´ım.
1
2 Autentizace a autorizace v internetov´ ych aplikac´ıch Autentizace je proces ovˇeˇren´ı identity uˇzivatele nebo jin´eho subjektu. Probˇehneli u ´spˇeˇsnˇe proces autentizace, doch´az´ı k autorizaci, tedy ke schv´alen´ı a umoˇznˇen´ı pˇr´ıstupu k chr´anˇen´ ym zdroj˚ um. Obvykle je autentizace uˇzivatele provedena nˇekterou z n´asleduj´ıc´ıch metod: • Podle znalost´ı uˇ zivatele - zpravidla jm´eno a heslo nebo PIN. • Podle prostˇ redk˚ u uˇ zivatele - obvykle technick´ y prostˇredek, kter´ y uˇzivatel vlastn´ı - certifik´at, hardwarov´ y kl´ıˇc. • Podle biometrick´ ych vlastnost´ı - napˇr. otisk prstu, s´ıtnice, hlasov´ y vzor. • Podle schopnost´ı uˇ zivatele - odpovˇed’ na nˇejakou ot´azku, kterou znaj´ı pouze uˇzivatel´e, kteˇr´ı by k dan´emu zdroji mˇeli m´ıt pˇr´ıstup. Tento zp˚ usob se vyuˇz´ıv´a napˇr. pˇri pˇr´ıstupu k sekc´ım webov´ ych str´anek patˇr´ıc´ıch pouze nˇekter´e skupinˇe, kter´a by odpovˇed’ na ot´azku mˇela zn´at (viz zabezpeˇcovac´ı mechanismus tˇr´ıdn´ıch str´anek na spoluzaci.cz). K autentizaci doch´az´ı u webov´ ych aplikac´ı po splnˇen´ı jedn´e z n´asleduj´ıc´ıch metod. V pˇr´ıpadˇe u ´spˇeˇsn´eho pˇrihl´aˇsen´ı je obvykle vygenerov´an k uˇzivatelsk´ ym sessions1 unik´atn´ı kl´ıˇc, kter´ y je uchov´av´an v cookies2 prohl´ıˇzeˇce nebo pˇred´av´an pomoc´ı parametr˚ u pˇri komunikaci. Na program´atorovi je rozhodnut´ı, jak´ y zp˚ usob autentizace vyuˇzije. V posledn´ı dobˇe se ve webov´ ych aplikac´ıch vyuˇz´ıvaj´ı tyto mechanismy: 1. Formul´aˇrov´a autentizace - vlastn´ı autentizaˇcn´ı mechanismus 1
Sessions v HTTP d´ av´ a serveru moˇznost uloˇzit si omezen´e mnoˇzstv´ı informac´ı o uˇzivateli, kter´ y k nˇemu pˇristupuje. Obvykle se tento mechanismus pouˇz´ıv´a k udrˇzen´ı kontextu o uˇzivatel´ıch jako m˚ uˇze b´ yt napˇr. udrˇzen´ı pˇrihl´aˇsen´ı uˇzivatele. 2 Cookies umoˇzn ˇuj´ı serveru uloˇzit mal´e mnoˇzstv´ı dat do prohl´ıˇzeˇce klienta. Pˇri kaˇzd´e n´ avˇstˇevˇe t´ehoˇz serveru pak prohl´ıˇzeˇc pos´ıl´a zpˇet data serveru aˇz do doby expirace dan´e cookie.
Formul´aˇrov´a autentizace je velmi pouˇz´ıvan´ y zp˚ usob autentizace. V pˇr´ıpadˇe potˇreby ovˇeˇren´ı pˇr´ıstupu k chr´anˇen´ ym zdroj˚ um je uˇzivatel poˇza´d´an o pˇr´ıstupov´e informace, kter´e zad´a pomoc´ı HTML formul´aˇre. Aplikace tyto u ´daje ovˇeˇr´ı a na z´akladˇe jejich korektnosti pˇridˇel´ı uˇzivateli unik´atn´ı identifik´ator, zpravidla uloˇzen´ y v session. Pot´e jiˇz nen´ı potˇreba v aplikaci d´ale kontrolovat jm´eno a heslo, ale pouze k´od uloˇzen´ y v session, kter´ y je platn´ y po celou dobu pr´ace v aplikaci nebo po serverem nastaven´em ˇcasov´em intervalu neˇcinnosti. Po vyprˇsen´ı platnosti session automaticky doch´az´ı k odhl´aˇsen´ı uˇzivatele. V´ yhody formul´aˇrov´e autentizace jsou zˇrejm´e: Spr´ava uˇzivatelsk´ ych u ´ˇct˚ u m˚ uˇze b´ yt pˇrizp˚ usobena pˇresnˇe podle potˇreb konkr´etn´ı sluˇzby, kter´a m´a nad sv´ ymi uˇzivateli kontrolu. Pro pˇrihl´aˇsen´ı se doporuˇcuje [7] pole pro zad´av´an´ı hesla zvolit typu password, jelikoˇz prohl´ıˇzeˇce text uloˇzen´ y v tomto poli maskuj´ı, a tak jej pˇr´ıpadn´ yu ´toˇcn´ık nem˚ uˇze pˇreˇc´ıst pouh´ ym pohledem. Formul´aˇr by mˇel b´ yt vˇzdy odesl´an pomoc´ı HTTP metody POST. V pˇr´ıpadˇe pouˇzit´ı GET se vˇsechna data vyplnˇen´a do formul´aˇre odes´ılaj´ı jako parametr na adresn´ı ˇra´dce prohl´ıˇzeˇce. T´ım p´adem tento ˇr´adek z˚ ust´av´a tak´e v historii prohl´ıˇzeˇce nebo v logovac´ıch souborech serveru. Nev´ yhodou formul´aˇrov´e autentizace je poˇzadavek na uˇzivatele, kter´ y si mus´ı pamatovat pˇr´ıstupov´e u ´daje k nˇekolika sluˇzb´am, kter´e vyuˇz´ıv´a. S postupem ˇcasu tˇechto sluˇzeb st´ale pˇrib´ yv´a a t´ım tak´e pˇrihlaˇsovac´ıch u ´daj˚ u.
2.2
Extern´ı autentizaˇ cn´ı poskytovatel
Jednou z nev´ yhod formul´aˇrov´e autentizace je nepˇrenositelnost identity a jej´ı nejednoznaˇcnost. Jedna identita je unik´atn´ı pouze v r´amci jedn´e sluˇzby nebo 3
Extern´ı autentizaˇcn´ı poskytovatel
skupiny sluˇzeb. V souˇcasn´e dobˇe se velmi rozˇsiˇruj´ı distribuovan´e webov´e sluˇzby (web services) a cloud computing3 . Uˇzivatel´e maj´ı v tˇechto sluˇzb´ach uloˇzen´a sv´a data a pravidelnˇe je pouˇz´ıvaj´ı. Sluˇzby jsou obvykle chr´anˇeny standardn´ım mechanismem, tedy jm´enem a heslem. Existuj´ı vˇsak takov´e, kter´e ovˇeˇruj´ı uˇzivatele napˇr. pomoc´ı ˇcipov´ ych karet, certifik´at˚ u apod. Poskytovatel˚ u sluˇzeb je velk´e mnoˇzstv´ı a mnoz´ı z nich poˇzaduj´ı od uˇzivatele tolik informac´ı pˇri registraci a uˇzivatel´e je natolik vyuˇz´ıvaj´ı, ˇze uˇzivatel v nich registrovan´ y se d´a prohl´asit za dostateˇcnˇe autorizovan´eho. Z´aroveˇ n s t´ımto faktem je tedy velmi ˇcasto spojeno propojov´an´ı aplikac´ı tˇret´ıch stran s tˇemito sluˇzbami. Tˇemto aplikac´ım je pak poskytnuta napˇr. moˇznost pˇren´est ovˇeˇren´ı nov´ ych i st´avaj´ıc´ıch uˇzivatel˚ u s vyuˇzit´ım faktu, ˇze uˇzivatel m´a jiˇz registrovan´ yu ´ˇcet na nˇekter´e ze sluˇzeb na internetu. Spr´ava identit pomoc´ı autentizaˇcn´ıho poskytovatele pˇrin´aˇs´ı tedy nˇekolik v´ yhod • Uˇzivatel nepotˇrebuje nov´e pˇrihlaˇsovac´ı u ´daje ke kaˇzd´e sluˇzbˇe. Staˇc´ı mu zn´at pouze heslo k u ´ˇctu u spr´avce identity. • Tato identita slouˇz´ı jako pˇrihlaˇsovac´ı kl´ıˇc k r˚ uzn´ ym sluˇzb´am. • Identita, pokud je spr´avnˇe vyplnˇena, jednoznaˇcnˇe identifikuje konkr´etn´ıho ˇclovˇeka. • Program´ator aplikace se nemus´ı starat o autentizaci a probl´emy s n´ı spojen´e (zabezpeˇcen´ y pˇrenos citliv´ ych u ´daj˚ u, obnova hesel apod.) Toto ˇreˇsen´ı sebou tak´e pˇrin´aˇs´ı nˇekolik nev´ yhod. Pro uˇzivatele je to zejm´ena probl´em v pˇr´ıpadˇe kompromitace jeho identity uloˇzen´e u autentizaˇcn´ı autority (napˇr. prozrazen´ı pˇrihlaˇsovac´ıch u ´daj˚ u). Pot´e je tato identita kompromitov´ana na vˇsech sluˇzb´ach, kter´e ji vyuˇz´ıvaj´ı. Spr´avci aplikace, kter´a na tato data spol´eh´a, ztr´ac´ı ˇc´ast kontroly nad informacemi o uˇzivatel´ıch a v d˚ usledku se mohou dostat do stavu, kdy o uˇzivateli znaj´ı pouze jeho ˇc´ıseln´ y identifik´ator. Mezi velk´e autentizaˇcn´ı autority patˇr´ı zejm´ena: 3
Cloud computing je model v´ yvoje zaloˇzen´ y na vyuˇz´ıv´an´ı zdroj˚ u uloˇzen´ ych v Internetu. Uˇzivatel pak k tˇemto zdroj˚ um m˚ uˇze pˇristupovat napˇr. pomoc´ı webov´eho prohl´ıˇzeˇce, program´ ator pak pomoc´ı webov´ ych sluˇzeb nebo API.
4
Extern´ı autentizaˇcn´ı poskytovatel
• Google.com • Facebook.com • Twitter.com • LinkedIn.com • Live.microsoft.com • Vimeo.com Tyto sluˇzby disponuj´ı rozs´ahlou datab´az´ı uˇzivatel˚ u a obvykle neposkytuj´ı pouze autentizaˇcn´ı mechanismy, ale tak´e moˇznost z´ıskat dalˇs´ı informace o uˇzivateli, pomoc´ı kter´ ych je pot´e moˇzn´e jej zaregistrovat do vlastn´ı aplikace s potˇrebn´ ymi u ´daji. Vˇetˇsina tˇechto sluˇzeb poskytuje autentizaˇcn´ı mechanismus pomoc´ı OpenID, LiveID nebo OAuth, zejm´ena ve verzi 2.0, kter´a rozˇsiˇruje OAuth 1.0 o dalˇs´ı funkˇcnosti.
2.2.1
OAuth
Dˇr´ıve bylo v aplikaci bˇeˇzn´e, ˇze pro naˇc´ıt´an´ı dat z jin´e sluˇzby, kterou uˇzivatel vyuˇz´ıv´a, bylo nutn´e zn´at jm´eno a heslo k jeho u ´ˇctu. Aplikace se pak pˇripojila pˇres API poˇzadovan´e sluˇzby a pot´e doch´azelo k v´ ymˇenˇe dat mezi aplikacemi. Tento zp˚ usob sebou nesl znaˇcnou m´ıru ned˚ uvˇery z formul´aˇr˚ u na internetov´ ych str´ank´ach a uˇzivatel´e se br´anili zad´av´an´ı sv´ ych pˇr´ıstupov´ ych dat do jin´ ych internetov´ ych aplikac´ı, neˇz do t´e, ke kter´e tyto u ´daje prim´arnˇe patˇr´ı. Pˇrihlaˇsovac´ı u ´daje k nˇekter´ ym sluˇzb´am jsou pro uˇzivatele mnohdy citlivˇejˇs´ı, neˇz je tomu u jin´ ych sluˇzeb. Jistˇe si z´akazn´ık v´ıce chr´an´ı pˇr´ıstup napˇr. ke sv´emu u ´ˇctu u Google, kter´ y je spojen s vˇetˇsinou sluˇzeb, jeˇz Google poskytuje, neˇz tˇreba u ´ˇcet na Twitter.com, jenˇz je ve zjednoduˇsen´em pojet´ı pouze pˇr´ıstupem k pˇr´ıspˇevk˚ um, kter´e jsou i tak veˇrejn´e. Tento probl´em ˇreˇs´ı autentizaˇcn´ı mechanismus OAuth, kter´ y nepoˇzaduje po uˇzivateli jeho jm´eno ani heslo. V aplikaci je nyn´ı pouze tlaˇc´ıtko ”Pˇrihl´asit pomoc´ı sluˇzby XYZ”, na kter´e kdyˇz klikne, je pˇresmˇerov´an na str´anky sluˇzby, kde se pˇrihl´as´ı se sv´ ym jm´enem a heslem. Pot´e potvrd´ı, zda aplikace, ze kter´e pˇriˇsel, m˚ uˇze pˇristupovat k urˇcit´ ym dat˚ um, kter´e si vyˇza´dala (pomoc´ı parametr˚ u v odkazu pro pˇrihl´aˇsen´ı). Nyn´ı se vygeneruje unik´atn´ı identifikaˇcn´ı 5
Extern´ı autentizaˇcn´ı poskytovatel
kl´ıˇc pro danou aplikaci s urˇcit´ ymi vlastnostmi (viz 2.2.1 - Token). Riziko zneuˇzit´ı je tedy minimalizov´ano a citliv´e pˇrihlaˇsovac´ı u ´daje jsou zad´av´any pouze c´ılov´e sluˇzbˇe. Na pozad´ı prob´ıhaj´ı operace, pˇri kter´ ych se vymˇen ˇuj´ı data pomoc´ı protokolu HTTP. Tyto operace se liˇs´ı v z´avislosti na pouˇzit´e verzi OAuth a nejsou v´az´any na konkr´etn´ı API ani platformu aplikace. Lze tedy OAuth vyuˇz´ıt jak v desktopov´e, tak ve webov´e aplikaci. OAuth je moment´alnˇe ve dvou verz´ıch (1.0 a 2.0). U obou je nutn´e pro jeho pouˇz´ıv´an´ı splnit nˇekolik poˇzadavk˚ u: 1. Registrace aplikace - Nejprve je nutn´e na stranˇe poskytovatele ovˇeˇren´ı zaregistrovat aplikaci, ze kter´e bude vznikat poˇzadavek na ovˇeˇren´ı. 2. Nastaven´ı vlastnost´ı aplikace - Poskytovatel ovˇeˇren´ı pˇridˇel´ı aplikaci identifik´ator a tajn´ y kl´ıˇc (ˇretˇezec). Ty je nutn´e si uloˇzit, jelikoˇz budou pouˇzity d´ale pˇri komunikaci nejen pˇri autentizaci uˇzivatele. 3. Nastaven´ı Callback URL - Adresa pro pˇresmˇerov´an´ı zpˇet do aplikace po u ´spˇeˇsn´e autentizaci na stranˇe poskytovatele. Komunikace prob´ıh´a tak, ˇze aplikace si nejprve vyˇz´ad´a jednor´azov´ y token (code), pot´e pˇresmˇeruje pomoc´ı HTTP uˇzivatele na str´anky poskytovatele autentizace, spoleˇcnˇe s t´ımto tokenem a poˇzadavkem na poˇzadovan´ y rozsah informac´ı, kter´e aplikace poˇzaduje. Poskytovatel ovˇeˇr´ı uˇzivatele a pot´e je dot´az´an, zda souhlas´ı s poskytnut´ım poˇzadovan´ ych zdroj˚ u aplikaci, ze kter´e pˇriˇsel. V pˇr´ıpadˇe souhlasu je vygenerov´an nov´ y token, kter´ y slouˇz´ı jako pˇr´ıstupov´ y kl´ıˇc, kter´ ym pak aplikace pˇristupuje k API poskytovatele. Cel´ y postup je graficky zn´azornˇen na obr. 2.1.
Token Token reprezentuje povolen´ı k pˇr´ıstupu aplikace k dat˚ um uloˇzen´ ym ve vzd´alen´em uloˇziˇsti. Jedn´a se o ˇretˇezec, kter´ y m´a v sobˇe zak´odovan´e nˇekter´e dalˇs´ı informace jako jsou rozsah pˇr´ıstupu aplikace k dat˚ um a ˇcas vyprˇsen´ı pˇr´ıstupu k nim pomoc´ı tohoto povolen´ı.
6
Extern´ı autentizaˇcn´ı poskytovatel Uživatel
Aplikace
Poskytovatel služby
Žádost o vstup do aplikace Žádost o ověření uživatele
Žádost uživatele o poskytnutí potřebných oprávnění
Rozhodnutí uživatele
Přístupový token
Žádost o uživatelská data
Objekt s daty
Přihlášení uživatele
Obr´azek 2.1: Autentizace a pˇrihl´aˇsen´ı uˇzivatele pomoc´ı OAuth 2.0 JSON objekty JavaScript Object Notation neboli JSON je form´at pro v´ ymˇenu strukturovan´ ych dat, kter´ y lze snadno ˇc´ıst i zapisovat. Jedn´a se textov´ y form´at, nez´avisl´ y na programovac´ım jazyku, kter´ y vyuˇz´ıv´a podobn´e konvence programovac´ıch jazyk˚ u rodiny C (C, C++, C#, Java, JavaScript a dalˇs´ı). Pˇr´ıklad jednoduch´eho JSON objektu nesouc´ıho z´akladn´ı informace o uˇzivateli: { "name": "John Doe", "address": { "streetAddress": "Vaclavske namesti", "city": "Prague", }, "phoneNumber": [{ "type": "home", "number": "212 555-1234" }, { "type": "fax", "number": "646 555-4567" }] } 7
Extern´ı autentizaˇcn´ı poskytovatel
Tento form´at v souˇcasn´e dobˇe podporuje vˇetˇsina programovac´ıch jazyk˚ u a je tedy velmi vhodn´ y pro v´ ymˇenu dat mezi aplikacemi. Zp˚ usob pˇrenosu informac´ı pˇres JSON objekty vyuˇz´ıvaj´ı sluˇzby jako napˇr. Facebook nebo Twitter v pˇr´ıpadˇe, ˇze autorizovan´a aplikace poˇzaduje informace z jejich komunikaˇcn´ıch rozhran´ı. Jeho v´ yhodou oproti XML je zejm´ena vyˇsˇs´ı m´ıra zjednoduˇsen´ı z´apisu oproˇstˇen´ım od parametr˚ u pˇr´ımo v objektech XML soubor˚ u.
2.2.2
OpenID
OpenID je otevˇren´ y standard, kter´ y popisuje zp˚ usoby autentizace uˇzivatel˚ u. Decentralizovan´ y je proto, ˇze nen´ı z´avisl´ y na ˇza´dn´em centr´aln´ım poskytovateli autentizace. Jeho v´ yhodou je opˇet skuteˇcnost, ˇze autentizace je celkovˇe v roli poskytovatele a nen´ı nijak pˇredepsan´a. Je tedy moˇzn´e uˇzivatele ovˇeˇrovat standardnˇe pomoc´ı jm´ena, hesla a k tomu pˇridat napˇr. ovˇeˇren´ı ˇcipov´e karty nebo biometrick´ ych vlastnost´ı uˇzivatele. To znamen´a, ˇze si uˇzivatel m˚ uˇze zvolit takovou autentizaˇcn´ı autoritu, kter´a mu bude vyhovovat jak z hlediska autority, kterou bude pouˇz´ıvat, tak z pohledu u ´rovnˇe zabezpeˇcen´ı, kde se m˚ uˇze sn´aze pˇredej´ıt odcizen´ı elektronick´e identity nebo kompromitaci dat. OpenID zav´ad´ı nˇekolik term´ın˚ u, kter´e je potˇreba zn´at pro pochopen´ı jeho principu. Tyto identifik´atory jsou detailnˇe pops´any ve specifikaci OpenID [4]. • Identifik´ ator (Identifier) - Jednoznaˇcn´a URI vˇcetnˇe protokolu (http, https) nebo XRI4 . V pˇr´ıpadˇe, ˇze je poskytovatel Google, je toto URI napˇr. https://profiles.google.com/vlasimsky.jiri. • Poskytovatel (OpenID Provider - OP) - Server poskytuj´ıc´ı potvrzen´ı o tom, ˇze konkr´etn´ımu uˇzivateli patˇr´ı konkr´etn´ı identifik´ator (server prov´adˇej´ıc´ı autentizaci). • OP Identifik´ ator (OpenID Provider Identificator) - Identifik´ator poskytovatele. • OP Endpoint (OpenID Provider Endpoint URL) - Koncov´ y bod OP ve formˇe URL s http nebo https, na kter´em poskytovatel pˇrij´ım´a poˇzadavky klient˚ u. 4 Extensible Resource Identifier - sch´ema a protokol pro abstraktn´ı identifik´atory kompatibiln´ı s URI. Pouˇz´ıv´a se zejm´ena u strukturovan´ ych web˚ u. (napˇr. xri://broadview.library.example.com/(urn:isbn:0-395-36341-1)/(+reference)
8
Extern´ı autentizaˇcn´ı poskytovatel
• Klient (Relying Party - RP) - Klient spol´eh´a na ovˇeˇren´ı identity od OP. Zpravidla se jedn´a o web, kter´ y implementuje moˇznost pˇr´ıstupu k vlastn´ım sluˇzb´am pˇres OpenID. • Uˇ zivatelsk´ y klient (User-Agent) - Jedn´a se o webov´eho klienta, kter´ y implementuje protokol HTTP/1.1. V naˇsem pˇr´ıpadˇe se bude jednat pouze o webov´ y prohl´ıˇzeˇc. • Uˇ zivatelem poskytnut´ y identifik´ ator (User-Supplied Identifier - USID) - Identifik´ator, kter´ y si uˇzivatel vybral na stranˇe poskytovatele. Uˇzivatel si m˚ uˇze vybrat, zda bude zad´avat sv˚ uj identifik´ator nebo OP identifik´ator - v tomto pˇr´ıpadˇe si uˇzivatel pozdˇeji vybere, pod kter´ ym identifik´atorem chce b´ yt pˇrihl´aˇsen (toto nab´ıdne poskytovatel). • Pˇ ridˇ elen´ y identifik´ ator (Claimed Identifier) - Jedn´a se o normalizovan´ y identifik´ator, kter´ y je urˇcen z URI nebo XRI.
Komunikace pˇ ri pouˇ zit´ı OpenID V pˇr´ıpadˇe, ˇze se uˇzivatel chce pˇrihl´asit na str´anky nˇejak´e sluˇzby pomoc´ı sv´eho OpenID u ´ˇctu, mus´ı nejprve zadat sv˚ uj identifik´ator do pole pro OpenID pˇrihl´aˇsen´ı. Klient normalizuje dodan´ y identifik´ator a pot´e z´ısk´a adresu OP Endpoint procesem zvan´ ym Discovery (v´ıce v [3]). Nyn´ı si klient a poskytovatel vymˇen´ı kl´ıˇc, kter´ ym bude poskytovatel podepisovat data, a klient tak m˚ uˇze ovˇeˇrit jejich pravost (tento krok je voliteln´ y). D´ale klient pˇresmˇeruje uˇzivatel˚ uv prohl´ıˇzeˇc na str´anky poskytovatele s poˇzadavkem na autentizaci. Poskytovatel ovˇeˇr´ı, zda je uˇzivatel opravdu majitelem zadan´eho ID. Mechanismus ovˇeˇren´ı je zcela v kompetenci poskytovatele a kaˇzd´ y poskytovatel si m˚ uˇze vyˇz´adat jin´a data jako napˇr. kombinaci jm´ena, hesla a nˇejak´e formy biometrick´eho ovˇeˇren´ı. Nyn´ı je uˇzivatel autentizov´an a pˇresmˇerov´an zpˇet na str´anky klienta, kter´ y ovˇeˇr´ı data pˇredan´a poskytovatelem. Kontroluje se zejm´ena n´avratov´e URL, Informace o endpointu, k´od poˇzadavku (tzv. nonce k´od) a ovˇeˇruje se podpis, bud’ pomoc´ı spoleˇcn´eho kl´ıˇce dohodnut´eho dˇr´ıve, nebo dalˇs´ım dotazem na poskytovatele. Cel´ y mechanismus je zobrazen na obr. 2.2.
9
Extern´ı autentizaˇcn´ı poskytovatel
Uživatel
Aplikace
Uživatel zadá svůj identifikátor
Poskytovatel služby
Discovery zjištění adresy OpenID providera
Výměna klíčů
Přesměrování uživatele Přesměrování na OpenID Providera Žádost uživatele o poskytnutí potřebných oprávnění Rozhodnutí uživatele Informace o autentizaci Přihlášení uživatele
3 Pr´avn´ı aspekty uchov´av´an´ı neuroinformatick´ ych dat Pro u ´ˇcely aplikace EEG/ERP port´alu jsou od mˇeˇren´ ych osob poˇzadov´any jejich osobn´ı u ´daje, pˇriˇcemˇz nˇekter´e jsou dle z´akona ˇc. 101/2000 Sb. klasifikov´any jako citliv´e. Z´akon ˇc. 101/2000 Sb., o ochranˇe osobn´ıch u ´daj˚ u slouˇz´ı k naplnˇen´ı pr´ava kaˇzd´eho na ochranu pˇred neopr´avnˇen´ ym zasahov´an´ım do soukrom´ı, upravuje pr´ava a povinnosti pˇri zpracov´an´ı osobn´ıch u ´daj˚ u a stanov´ı podm´ınky, za nichˇz se uskuteˇcn ˇuje pˇred´an´ı osobn´ıch u ´daj˚ u do jin´ ych st´at˚ u (pˇrevzato z [12]).
Osobn´ı u ´ daj §4. odst. a a) osobn´ım u ´dajem je jak´akoliv informace t´ykaj´ıc´ı se urˇcen´eho nebo urˇciteln´eho subjektu u ´daj˚ u. Subjekt u ´daj˚ u se povaˇzuje za urˇcen´y nebo urˇciteln´y, jestliˇze lze subjekt u ´daj˚ u pˇr´ımo ˇci nepˇr´ımo identifikovat zejm´ena na z´akladˇe ˇc´ısla, k´odu nebo jednoho ˇci v´ıce prvk˚ u, specifick´ych pro jeho fyzickou, fyziologickou, psychickou, ekonomickou, kulturn´ı nebo soci´aln´ı identitu,
Citliv´ yu ´ daj §4, odst. b) citliv´ym u ´dajem je osobn´ı u ´daj vypov´ıdaj´ıc´ı o n´arodnostn´ım, rasov´em nebo etnick´em p˚ uvodu, politick´ych postoj´ıch, ˇclenstv´ı v odborov´ych organizac´ıch, n´aboˇzenstv´ı a filozofick´em pˇresvˇedˇcen´ı, odsouzen´ı za trestn´y ˇcin, zdravotn´ım stavu a sexu´aln´ım ˇzivotˇe subjektu u ´daj˚ u a genetick´y u ´daj subjektu u ´daj˚ u; citliv´ym u ´dajem je tak´e biometrick´y u ´daj, kter´y umoˇzn ˇuje pˇr´ımou identifikaci nebo autentizaci subjektu u ´daj˚ u, Tˇemito u ´daji jsou v pˇr´ıpadˇe zpracov´an´ı neuroinformatick´ ych dat v aplikaci port´alu (viz pˇr´ıloha B - ERP Metadata): • Osobn´ı u ´daje – Jm´eno a pˇr´ıjmen´ı – Datum narozen´ı – Pohlav´ı – Kontakt
Svolen´ı k uchov´av´an´ı osobn´ıch u ´daj˚ u je d´ano §11 z´akona ˇc. 101/2000 sb.1 . (1) Spr´avce je pˇri shromaˇzd’ov´an´ı osobn´ıch u ´daj˚ u povinen subjekt u ´daj˚ u informovat o tom, v jak´em rozsahu a pro jak´ yu ´ˇcel budou osobn´ı u ´daje zpracov´any, kdo a jak´ ym zp˚ usobem bude osobn´ı u ´daje zpracov´avat a komu mohou b´ yt osobn´ı u ´daje zpˇr´ıstupnˇeny, nejsou-li subjektu u ´daj˚ u tyto informace jiˇz zn´amy. Spr´avce mus´ı subjekt u ´daj˚ u informovat o jeho pr´avu pˇr´ıstupu k osobn´ım u ´daj˚ um, pr´avu na opravu osobn´ıch u ´daj˚ u, jakoˇz i o dalˇs´ıch pr´avech stanoven´ ych v § 21. (2) V pˇr´ıpadˇe, kdy spr´avce zpracov´av´a osobn´ı u ´daje z´ıskan´e od subjektu u ´daj˚ u, mus´ı subjekt u ´daj˚ u pouˇcit o tom, zda je poskytnut´ı osobn´ıho u ´daje povinn´e ˇci dobrovoln´e. Je-li subjekt u ´daj˚ u povinen podle zvl´aˇstn´ıho z´akona osobn´ı u ´daje pro zpracov´an´ı poskytnout, pouˇc´ı jej spr´avce o t´eto skuteˇcnosti, jakoˇz i o n´asledc´ıch odm´ıtnut´ı poskytnut´ı osobn´ıch u ´daj˚ u. (5) Pˇri zpracov´an´ı osobn´ıch u ´daj˚ u podle § 5 odst. 2 p´ısm. e) a § 9 p´ısm. h) je spr´avce povinen bez zbyteˇcn´eho odkladu subjekt u ´daj˚ u informovat o zpracov´an´ı jeho osobn´ıch u ´daj˚ u. Zpracov´an´ı citliv´ ych u ´daj˚ u upˇresˇ nuje §9 z´akona ˇc. 101/2000. a) subjekt u ´daj˚ u dal ke zpracov´an´ı v´yslovn´y souhlas. Subjekt u ´daj˚ u mus´ı b´yt pˇri udˇelen´ı souhlasu informov´an o tom, pro jak´y u ´ˇcel zpracov´an´ı a k jak´ym osobn´ım u ´daj˚ um je souhlas d´av´an, jak´emu spr´avci a na jak´e obdob´ı. Existenci souhlasu subjektu u ´daj˚ u se zpracov´an´ım osobn´ıch u ´daj˚ u mus´ı b´yt 1
Vybr´ any byly pouze odstavce t´ ykaj´ıc´ı se EEG/ERP port´alu, cel´e znˇen´ı z´akona je uvedeno v [12]
12
Souhlas s uchov´an´ım osobn´ıch u ´daj˚ u
spr´avce schopen prok´azat po celou dobu zpracov´an´ı. Spr´avce je povinen pˇredem subjekt u ´daj˚ u pouˇcit o jeho pr´avech podle § 12 a 21, Pozn. zm´ınˇen je pouze odstavec (a), kter´ y se t´ yk´a aplikace. Cel´e znˇen´ı viz [12].
3.2
Souhlas s uchov´ an´ım osobn´ıch u ´ daj˚ u
Neˇz je provedeno mˇeˇren´ı je mˇeˇren´a osoba obezn´amena s u ´daji, kter´e budou zpracov´any, jak s nimi bude nakl´ad´ano a jak prob´ıh´a pr˚ ubˇeh mˇeˇren´ı (viz pˇr´ıloha A - Podm´ınky u ´ˇcasti v projektu s n´azvem Mˇeˇren´ı mozkov´e aktivity“ ” a pˇr´ıloha B - ERP Metadata).
Pˇ resn´ e znˇ en´ı: Podpisem tˇechto podm´ınek u ´ˇcasti v projektu udˇeluji ve smyslu z´akona ˇc. 101/2000 Sb., o ochranˇe osobn´ıch u ´daj˚ u a o zmˇenˇe nˇekter´ych z´akon˚ u, ve znˇen´ı pozdˇejˇs´ıch pˇredpis˚ u Z´apadoˇcesk´e univerzitˇe v Plzni a Fakultn´ı nemocnici Plzeˇ n po pouˇcen´ı o sv´ych pr´avech v´yslovn´y souhlas se zpracov´an´ım osobn´ıch a citliv´ych u ´daj˚ u v rozsahu tˇechto podm´ınek u ´ˇcasti v projektu, vˇcetnˇe pˇr´ılohy, kter´a je ned´ılnou souˇc´ast´ı tohoto pouˇcen´ı, za u ´ˇcelem realizace a n´asledn´eho vyhodnocen´ı projektu. Tento souhlas udˇeluji na dobu realizace projektu a n´aslednˇe po dobu . . . 5. . . let po jeho skonˇcen´ı. Jsem si vˇedom(a) toho, ˇze poskytnut´ı osobn´ıch a citliv´ych u ´daj˚ u je dobrovoln´e, a ˇze souhlas se zpracov´an´ım osobn´ıch nebo citliv´ych u ´daj˚ u mohu kdykoli odvolat. Ukl´ad´an´ı osobn´ıch a citliv´ ych dat je tedy v aplikaci v souladu se z´akonem ˇc. 101/2000 Sb a dokumenty, kter´e jsou mˇeˇrenou osobou vyplnˇeny, jsou tak´e v souladu s t´ımto z´akonem.
13
4 Technologie pouˇzit´e pˇri ˇreˇsen´ı autentizace a autorizace v EEG/ERP port´ alu Cel´a webov´a aplikace EEG/ERP port´alu je vytvoˇrena v programovac´ım jazyce JAVA s vyuˇzit´ım kombinace technologi´ı: 1. Spring Framework 2.5 2. Spring Security 2.0 3. Hibernate
4.1
Spring Framework
Program´ator pˇri v´ yvoji netrivi´aln´ıch aplikac´ı ˇcasto potˇrebuje bˇeˇznˇe se vyskytuj´ıc´ı aspekty n´avrhu, jak´ ymi jsou napˇr´ıklad autentizace, autorizace, ukl´ad´an´ı dat do datab´aze, spr´ava transakc´ı apod. D´ale je u aplikac´ı probl´em se strukturov´an´ım k´odu, kter´ y sice lze ˇreˇsit vyuˇzit´ım n´avrhov´ ych vzor˚ u, ale i takov´ato dekompozice pˇredstavuje neust´ale se opakuj´ıc´ı obdobn´e kusy k´odu. V aplikaci je vyuˇzito open-source frameworku1 Spring Framework ve verzi 2.5, kter´ y je urˇcen pro v´ yvoj J2EE aplikac´ı. Tento framework ˇreˇs´ı v´ yˇse uveden´e probl´emy tak, ˇze bˇeˇznˇe opakuj´ıc´ı se funkce aplikac´ı implementuje ve sv´ ych tˇr´ıd´ach a t´ım poskytuje v´ yvoj´aˇri jiˇz hotovou infrastrukturu, kterou aplikace vyuˇz´ıvaj´ı (v´ıce v [2]). Jednou z vlastnost´ı Spring Framework je spr´ava ˇzivotn´ıho cyklu aplikace a k´od aplikace je j´ım v poˇzadovan´ ych chv´ıl´ıch vol´an. T´ımto je zajiˇstˇen pˇresun kontroly bˇehu aplikace na framework. Pˇredpokladem pro tento fakt je nutnost spr´avn´e strukturovanosti a dekompozice aplikace, kterou framework pˇredepisuje. Velmi ˇcasto se jedn´a pr´avˇe o rozˇs´ıˇren´e n´avrhov´e vzory. 1
za framework lze oznaˇcit komplexn´ı aplikaˇcn´ı servery, webov´e kontejnery jako napˇr. Apache Tomcat ˇci odlehˇcen´e a specializovan´e r´amce, kter´ ymi jsou napˇr. Spring Framework, WebWord ˇci Struts.
14
Spring Security
4.1.1
Dependency Injection (Inversion of Control)
Spring Framework je oznaˇcov´an jako IoC kontejner. Inversion of Control (IoC) je n´avrhov´ y vzor, kter´ y umoˇzn ˇuje pˇrev´est kontrolu z´avislosti tˇr´ıdy na jin´ ych komponent´ach mimo tuto tˇr´ıdu. Ve v´ ysledku to znamen´a, ˇze komponenty, na kter´ ych je tˇr´ıda z´avisl´a jsou j´ı nastaveny (angl. injected) t´ımto n´avrhov´ ym vzorem. Z tohoto d˚ uvodu bylo IoC pozdˇeji pˇrejmenov´ano na Dependency Injection (DI). S´ıt’ vytv´aˇren´ ych objekt˚ u je definov´ana napˇr. v konfiguraˇcn´ım souboru (obvykle XML), na jehoˇz z´akladˇe framework zajist´ı, aby objekty byly vz´ajemnˇe prov´az´any. Framework pro tento u ´kon vyuˇz´ıv´a ”set”metod (Setter Injection) a konstruktor˚ u (Constructor Injection). Detailnˇeji je pops´an tento n´avrhov´ y vzor v [2].
4.2
Spring Security
Spring security je bezpeˇcnostn´ı framework, kter´ y poskytuje zabezpeˇcen´ı pro aplikace zaloˇzen´ ych na frameworku Spring. Tento framework umoˇzn ˇuje komplexn´ı moˇznost pro zabezpeˇcen´ı aplikace. Detailnˇe je Spring Security pops´an v referenˇcn´ı dokumentaci [1] a je mu vˇenov´ana kapitola v knize Spring In Action [2]. V pˇr´ıpadˇe zabezpeˇcen´ı webov´ ych aplikac´ı vyuˇz´ıv´a Spring Security servletov´e filtry, kter´e zachycuj´ı poˇzadavky na servlety tak, aby nejprve byla provedena autentizace a autorizace, a t´ım bylo zajiˇstˇeno zabezpeˇcen´eho pˇr´ıstupu k chr´anˇen´ ym zdroj˚ um. Obvykle je zabezpeˇcov´an pˇr´ıstup k cel´emu bloku programu, zejm´ena obsluˇzn´ ych kontroler˚ u. Tento framework vˇsak tak´e umoˇzn ˇuje prov´est zabezpeˇcen´ı na u ´rovni vol´an´ı metod. Lze tedy zabezpeˇcit kaˇzdou metodu zvl´aˇst’ podle poˇzadovan´eho opr´avnˇen´ı k jej´ımu proveden´ı (napˇr. mazat pˇr´ıspˇevky je umoˇznˇeno pouze uˇzivateli s u ´rovn´ı opr´avnˇen´ı ROLE_ADMIN.
15
Hibernate
4.3
Hibernate
Hibernate je framework, kter´ y zajiˇst’uje objektovˇe-relaˇcn´ı mapov´an´ı (ORM) tˇr´ıd programovac´ıho jazyka na tabulky datab´aze. Tento framework poskytuje mechanismy jako napˇr. transakˇcn´ı zpracov´an´ı dat, cache objekt˚ u a obsahuje vlastn´ı dialekt jazyka SQL pro pr´aci s daty zvan´ y HQL neboli Hibernate Query Language. Ten dok´aˇze na z´akladˇe objektov´e notace manipulovat s daty v datab´azi jako s objekty. Hibernate pouˇz´ıv´a pro mapov´an´ı objekt˚ u tzv. mapovac´ı soubory, kter´e obsahuj´ı informace o tom, jak´ ym zp˚ usobem budou propojeny tabulky datab´aze s objekty aplikace, kter´e se v programovac´ım jazyce Java naz´ yvaj´ı Plain Old Java Object (POJO). Soubory je moˇzn´e mapovat i pomoc´ı anotac´ı pˇr´ımo v POJO objektu a u metod kontroler˚ u, k doc´ılen´ı stejn´eho efektu jako v pˇr´ıpadˇe mapovac´ıch soubor˚ u. V´ yhodou Hibernate je usnadnˇen´ı pr´ace program´atorovi, kter´ y nemus´ı upravovat relace mezi objekty ruˇcnˇe, ale m˚ uˇze tuto pr´aci pˇrenechat zm´ınˇen´emu frameworku. Dalˇs´ı v´ yhodou je vyuˇzit´ı HQL, kter´e eliminuje nutnost pouˇz´ıt pro jin´ y typ datab´azov´eho syst´emu jin´ y dotazovac´ı jazyk.
4.4
Message-Digest Algorithm - MD5
MD5 je velmi rozˇs´ıˇren´a hash2 funkce, jej´ıˇz v´ ystupem je 128 bit˚ u dlouh´ y otisk reprezentovan´ y 32 hexadecim´aln´ımi znaky. V programovac´ım jazyce Java bylo vyuˇzito funkce ControllerUtils.getMD5String(String text);, kter´a jako sv˚ uj parametr pˇrej´ım´a libovoln´ y ˇretˇezec a jej´ım v´ ystupem je MD5 otisk, kter´ y tomuto vstupu odpov´ıd´a. Napˇr. v pˇr´ıpadˇe zad´an´ı uˇzivatelsk´eho hesla abc123 bude v´ ystupem funkce pro pˇrevod do MD5 ˇretezec: e99a18c428cb38d5f260853678922e03 V pˇr´ıpadˇe zad´an´ı hesla abc124 bude v´ ystupem funkce: 2
Hash je reprodukovateln´ a metoda pro pˇrevod dat do posloupnosti znak˚ u, kter´e vytv´aˇr´ı jejich jednoznaˇcnou charakteristiku.
16
Message-Digest Algorithm - MD5
b71a4cd635e0ea3e43adcc1e0c755416 Je tedy zˇrejm´e, ˇze i pˇri mal´e zmˇenˇe vstupn´ıho ˇretˇezce se v´ yraznˇe zmˇen´ı ˇretˇezec v´ ystupn´ı.
17
5 Bezpeˇcnost internetov´ych aplikac´ı Bezpeˇcnost internetov´ ych aplikac´ı je kv˚ uli rostouc´ımu mnoˇzstv´ı citliv´ ych dat v tˇechto aplikac´ıch velmi z´avaˇzn´ ym t´ematem. EEG/ERP port´al je webov´a aplikace, kter´a v datab´azi uchov´av´a uˇzivatelsk´a osobn´ı data, zdravotn´ı u ´daje a dalˇs´ı nezanedbateln´e mnoˇzstv´ı dat, ke kter´ ym je potˇreba odepˇr´ıt pˇr´ıstup neopr´avnˇen´ ym osob´am.
5.1
Rizika v roce 2010 podle OWASP
Sdruˇzen´ı The Open Web Application Security Project neboli OWASP se zab´ yv´a bezpeˇcnost´ı webov´ ych aplikac´ı v nˇekolika sv´ ych projektech. Jedn´ım z tˇechto projekt˚ u je tak´e tzv. OWASP Top Ten (viz [6]). V r´amci tohoto projektu je od roku 2002 kaˇzdoroˇcnˇe vyd´av´an seznam deseti nejkritiˇctˇejˇs´ıch probl´em˚ u webov´ ych aplikac´ı v pˇredeˇsl´em roce. Jelikoˇz tyto probl´emy souvis´ı nejen s autentizac´ı, ale pˇrev´aˇznˇe s autorizac´ı pˇr´ıstupu k chr´anˇen´ ym zdroj˚ um, byl tento seznam pouˇzit pro testov´an´ı bezpeˇcnosti aplikace EEG/ERP port´alu. N´asleduj´ıc´ı kapitoly jsou rozdˇeleny podle seznamu OWASP Top Ten 2010.
Injection ´ Injection je napaden´ı aplikace vsunut´ım k´odu pˇres neoˇsetˇren´ y vstup. Utok je proveden takov´ ym zp˚ usobem, ˇze u ´toˇcn´ık sv˚ uj ˇskodliv´ y k´od pˇredloˇz´ı jako souˇc´ast poˇzadavku nebo pˇr´ıkazu, kter´ y je d´ale zpracov´av´an obsluˇzn´ ym k´odem aplikace. V pˇr´ıpadˇe u ´spˇeˇsn´eho proveden´ı u ´toˇcn´ıkova k´odu m˚ uˇze doj´ıt k naruˇsen´ı bezpeˇcnosti nˇekter´e z vrstev aplikace. Obvykle se u webov´ ych aplikac´ı jedn´a o datovou vrstvu.
SQL Injection SQL Injection je u ´tok na datab´azov´ y syst´em, kter´ y aplikace vyuˇz´ıv´a. Jeho c´ılem je z´ısk´an´ı kontroly nad datab´az´ı bez nutnosti m´ıt k n´ı legitimn´ı pˇr´ıstup. V pˇr´ıpadˇe u ´spˇeˇsn´eho pr˚ uniku z´ısk´av´a u ´toˇcn´ık pˇr´ıstup ke stejn´e ˇca´sti 18
Rizika v roce 2010 podle OWASP
datab´aze, jako m´a aplikace ve chv´ıli prov´adˇen´ı ˇskodliv´eho k´odu, a u ´tok m˚ uˇze v´est ke zneuˇzit´ı nebo znehodnocen´ı dat. Jednoduch´ ym pˇr´ıkladem u ´toku m˚ uˇze b´ yt napˇr. napaden´ı pˇrihlaˇsovac´ıho formul´aˇre, na jehoˇz pozad´ı je n´ıˇze uveden´ y ovˇeˇrovac´ı SQL dotaz. sprintf(SELECT * FROM users WHERE login=’%s’ AND password=’%s’, login, password); Pozn. Jedn´a se pouze o ilustrativn´ı ovˇeˇrovac´ı dotaz. Nen´ı zde pouˇzito ˇz´adn´e ˇsifrov´an´ı ani nejsou oˇsetˇreny ˇz´adn´e znaky v promˇenn´ych login a password. V pˇr´ıpadˇe, ˇze u ´toˇcn´ık do pole login vloˇz´ı napˇr. administrator’ OR 1=1-, pak po sestaven´ı SQL dotazu vznikne jeho n´asleduj´ıc´ı podoba: SELECT * FROM users WHERE login=’administrator’ OR 1=1--’ AND password=’’; Doch´az´ı tedy k situaci, kdy se program snaˇz´ı naj´ıt nejprve uˇzivatele s pˇrihlaˇsovac´ım jm´enem administrator. Podm´ınka OR 1=1 je vˇzdy splnˇena a mnoho datab´azov´ ych syst´em˚ u vr´at´ı v t´eto situaci prvn´ı z´aznam v tabulce users, kter´ y tak´e mnohokr´at b´ yv´a pr´avˇe administr´atorsk´ y, jelikoˇz mohl b´ yt vytvoˇren spoleˇcnˇe s instalac´ı aplikace. Dvouznakov´ y ˇretˇezec ”--”znaˇc´ı ve skriptovac´ım jazyce SQL koment´aˇr a v pˇr´ıpadˇe v´ yˇse uveden´eho pˇr´ıkladu tedy doch´az´ı k zakomentov´an´ı ovˇeˇren´ı hesla (... AND password=") a t´ım k autentizaci pouze podle jm´ena nebo st´ale splnˇen´e podm´ınky ”OR 1=1”. V pˇr´ıpadˇe, ˇze nejsou oˇsetˇreny vstupn´ı parametry login a password, doch´az´ı vˇzdy ke splnˇen´ı ovˇeˇrovac´ı podm´ınky definovan´e v´ yˇse uveden´ ym SQL dotazem a u ´tok je pot´e u ´spˇeˇsn´ y.
Pˇ r´ıkaz UNION Dalˇs´ı variantou SQL injection je vyuˇzit´ı pˇr´ıkazu UNION, kter´ y dovoluje spojit v´ıce pˇr´ıkaz˚ u do jednoho dotazu. D´ıky tomu m˚ uˇze u ´toˇcn´ık ˇc´ıst informace i z jin´ ych tabulek, neˇz z t´e, nad kterou byl p˚ uvodnˇe dotaz ´ cn´ık se tak´e m˚ prov´adˇen. Utoˇ uˇze dostat v pˇr´ıpadˇe nˇekter´ ych souˇcasn´ ych datab´azov´ ych syst´em˚ u k information_schema, ve kter´em jsou uloˇzeny informace o datab´azi, jako napˇr. poˇcet tabulek, jejich n´azvy i definice jejich sloupc˚ u apod. V´ıce o t´eto problematice lze naj´ıt v [9]. 19
Rizika v roce 2010 podle OWASP
Cross Site Scripting (XSS) XSS u ´tok je technika, kter´a pˇrinut´ı webovou str´anku zobrazit ˇskodliv´ y k´od, kter´ y je spuˇstˇen v prohl´ıˇzeˇci n´avˇstˇevn´ıka str´anek. Tento k´od je velmi ˇcasto (ne vˇzdy) naps´an v HTML nebo JavaScriptu. Jedn´a se o velmi ˇcast´ y zp˚ usob u ´toku na webovou aplikaci, ve kter´e je umoˇznˇeno n´avˇstˇevn´ıkovi ovlivˇ novat obsah aplikace. Postaˇcuj´ıc´ım pr˚ unikem je pr´avˇe u ´spˇeˇsn´e vloˇzen´ı ˇskodliv´eho k´odu takov´ ym zp˚ usobem, aby n´avˇstˇevn´ık˚ uv prohl´ıˇzeˇc interpretoval k´od jako provediteln´ ya nikoli jako pouh´ y text. N´achylnost aplikace nemus´ı b´ yt pouze v pˇr´ıpadˇe internetov´eho prohl´ıˇzeˇce. V minulosti s XSS bojovali napˇr. tv˚ urci programu Apple QuickTime (v´ıce v [4]).
Vloˇ zen´ı ˇ skodliv´ eho k´ odu Skripty je moˇzn´e do str´anky vloˇzit nˇekolika zp˚ usoby: • <script>blok kodu; - blok k´odu • <script src=’http://www.hacker.urlscript.js’> - k´od ze str´anky u ´toˇcn´ıka • <script src=http://www.hacker.urlscript.js> - podobn´e, ale bez uvozovek, kter´e mohou u ´toˇcn´ıkovi zp˚ usobovat probl´emy, kdyˇz by mˇel server oˇsetˇren´e vstupy na vkl´ad´an´ı uvozovek • Dalˇs´ım zp˚ usobem je napˇr. vloˇzen´ı skriptu jako atributu do jin´ ych objekt˚ u DOM: <meta http-equiv=refresh content=0;url=javascript:alert(XSS);> <iframe src=javascript:alert(XSS);>
20
Rizika v roce 2010 podle OWASP
Je tedy zˇrejm´e, ˇze zp˚ usob˚ u, jak vynutit spuˇstˇen´ı vkl´adan´eho skriptu, je cel´a ˇrada a skript se jako atribut d´a vloˇzit takˇrka ke kaˇzd´emu objektu DOM.
Maskov´ an´ı XSS u ´ toku Jelikoˇz u ´toˇcn´ık potˇrebuje sn´ıˇzit riziko jeho odhalen´ı, jsou velmi ˇcasto pouˇzity maskovac´ı techniky, kter´e ˇskodliv´ y k´od skryj´ı tak, aby jej n´avˇstˇevn´ık str´anek nebo administr´ator neodhalil pouh´ ym pohledem na str´anku. Jednou z maskovac´ıch technik je konverze ˇskodliv´eho k´odu do uˇzivatelem neˇciteln´ ych hexadecim´aln´ıch hodnot. Napˇr. http://URL/stranka?captcha=<script>alert(’XSS!!’); je konvertov´an na: http://URL/stranka?captcha=%3C%73%63%72%69%70%74%3E%61%6C%65 %72%74%28%27%58%53%53%21%21%27%29%3B%3C%2F%73%63%72%69%70%74%3E T´ım dojde ke sn´ıˇzen´ı odhalitelnosti vloˇzen´eho skriptu. Uˇzivatel pravdˇepodobnˇe nic nepozn´a, pˇriˇcemˇz prohl´ıˇzeˇc interpretuje hexadecim´aln´ı znaky jako zdrojov´ y k´od a t´ım se u ´spˇeˇsnˇe provede XSS u ´tok. Dalˇs´ı moˇznost´ı je ukryt´ı ˇskodliv´eho k´odu do HTML koment´aˇre. T´ım nedojde k pˇr´ıpadn´emu poˇskozen´ı vzhledu zobrazen´e str´anky vznikl´eho napˇr. ukonˇcen´ım formul´aˇrov´eho prvku, jako je tomu v 7.1.2. Prohl´ıˇzeˇc vˇsak provede vloˇzen´ y skript bez ohledu, zda je v koment´aˇri, ˇci nikoliv.
Broken Authentication and Session Management Jedn´a se o u ´tok na aplikaci, kter´ y vyuˇz´ıv´a bezpeˇcnostn´ıch nedostatk˚ u ve vztahu k autentizaci a spr´avou sezen´ı (SESSIONS). C´ılem tohoto u ´toku je pˇrevz´ıt identitu uˇzivatele. Jak jiˇz bylo zm´ınˇeno v kapitole 2), existuj´ı r˚ uzn´e zp˚ usoby autentizace uˇzivatele. Po jejich u ´spˇeˇsn´em dokonˇcen´ı dost´av´a uˇzivatel unik´atn´ı kl´ıˇc k sessions uloˇzen´ ych na serveru. T´ım se pak identifikuje po celou dobu jeho platnosti 21
Rizika v roce 2010 podle OWASP
(obvykle do zavˇren´ı okna prohl´ıˇzeˇce). Tento kl´ıˇc se naz´ yv´a session id, je obvykle uloˇzen v cookies nebo je pˇred´av´an v adrese jako parametr. Existuj´ı moˇznosti, jak si tento session id zmˇenit. V pˇr´ıpadˇe, ˇze pˇr´ıstup k sessions nen´ı dostateˇcnˇe zabezpeˇcen (napˇr. pomoc´ı SSL), je moˇzn´e v pˇr´ıpadˇe znalosti session id jin´eho, pr´avˇe pˇrihl´aˇsen´eho uˇzivatele, pˇrevz´ıt jeho identitu. To m˚ uˇze v´ezt ke kompromitaci dat tohoto uˇzivatele.
Insecure Direct Object References ´ Utok spoˇc´ıv´a v naˇcten´ı obsahu, ke kter´emu u ´toˇcn´ık nem´a povolen pˇr´ıstup, pˇr´ım´ ym odkazem. Aplikace je n´achyln´a k tomuto typu u ´toku v pˇr´ıpadˇe, ˇze u chr´anˇen´ ych zdroj˚ u nekontroluje jejich pˇr´ısluˇsnost k uˇzivateli. Obvykle se jedn´a o pˇr´ıstup ke str´ance, souboru, adres´aˇri nebo datab´azov´emu kl´ıˇci. V tomto pˇr´ıpadˇe se zpravidla nejedn´a o opr´avnˇen´ı uˇzivatelsk´ ych rol´ı v syst´emu, ale o opr´avnˇen´ı pˇr´ımo k vyuˇzit´ı dan´eho zdroje. Aplikace je n´achyln´a zejm´ena na URL adresy, kter´e pˇreb´ıraj´ı nˇejak´ y parametr k zobrazov´an´ı obsahu. Napˇr. http://URL/person-detail?id=XX Je ilustrativn´ı adresa, ke kter´e by mˇel m´ıt uˇzivatel pˇr´ıstup pouze v pˇr´ıpadˇe, ˇze m´a dostateˇcn´a opr´avnˇen´ı k detailu XX. Probl´em vznik´a, pokud aplikace vyuˇz´ıv´a pro naˇc´ıt´an´ı v´ ysledk˚ u pouze jednoduch´ y SQL dotaz (viz n´ıˇze), pˇrej´ımaj´ıc´ı parametr, kter´ y m˚ uˇze u ´toˇcn´ık ovlivnit zmˇenou parametru v URL. V tomto pˇr´ıpadˇe parametru id. sprintf("SELECT * FROM osoby WHERE id = %d",id); ´ cn´ık m´a pˇr´ıstup pouze k detail˚ Utoˇ um nˇekter´ ych uˇzivatel˚ u, obvykle omezen´ y seznamem s odkazy na tyto detaily. V pˇr´ıpadˇe v´ yˇse uveden´eho SQL dotazu je moˇzn´e, aby zadal ID jin´eho uˇzivatele a jeho detaily se pot´e zobraz´ı stejn´ ym zp˚ usobem jako u detail˚ u, ke kter´ ym m´a bˇeˇznˇe pˇr´ıstup.
22
Rizika v roce 2010 podle OWASP
Cross Site Request Forgery Cross Site Request Forgery neboli CSRF je u ´tok na webovou aplikaci veden´ y z jin´e str´anky s vyuˇzit´ım poˇzadavk˚ u na obsluˇzn´e metody aplikace. Zpravidla m´a u ´toˇcn´ık pˇrehled o aplikaci a toku poˇzadavk˚ u, kter´e jsou v n´ı zpracov´av´any. Tyto vlastnosti mohl zjistit dˇr´ıve pozorov´an´ım str´anek, napˇr. po registraci, nebo nˇejak´ ym u ´tokem. Velmi ˇcasto se tento typ u ´toku vyuˇz´ıv´a, kdyˇz u ´toˇcn´ık potˇrebuje prov´est nˇejak´ y poˇzadavek, o kter´em v´ı, ˇze lze uˇzivatelsky prov´est, ale nem´a k nˇemu dostateˇcn´ y pˇr´ıstup. Princip t´eto metody je n´asleduj´ıc´ı: ´ cn´ık naˇsel URL adresu, kde je zpracov´av´an nˇejak´ 1. Utoˇ y poˇzadavek, na kter´ y je potˇreba jin´e opr´avnˇen´ı, neˇz u ´toˇcn´ıkovo st´avaj´ıc´ı. Napˇr. tento fiktivn´ı poˇzadavek, kter´ y zvyˇsuje hodnocen´ı ˇcl´ank˚ u. Uvaˇzujme, ˇze tento poˇzadavek je provediteln´ y pouze pro uˇzivatele, kteˇr´ı jsou registrov´ani a je omezen pouze na jedno moˇzn´e hlasov´an´ı. http://URL/actions.jsp?action=voteForArticle&id=1 ´ cn´ık vytvoˇr´ı str´anku, kde bude k´od, kter´ 2. Utoˇ y bude nˇejak´ ym zp˚ usobem volat v´ yˇse uveden´ y poˇzadavek pro zv´ yˇsen´ı hodnocen´ı ˇcl´anku. Napˇr. vloˇzen´ım neviditeln´eho iframe, jehoˇz obsahem bude str´anka s poˇzadavkem: <iframe src="http://URL/actions.jsp?action=voteForArticle&id=1" width=0 height=0 border=0 /> ´ cn´ık poˇsle uˇzivateli (nebo uˇzivatel˚ 3. Utoˇ um, napˇr. na diskuzn´ı f´orum) odkaz na svou str´anku. 4. Uˇzivatel str´anku otevˇre a s n´ı se z´aroveˇ n naˇcte iframe z bodu 1. V pˇr´ıpadˇe, ˇze je uˇzivatel pˇrihl´aˇsen v aplikaci, kter´a je vloˇzena jako iframe, je provedena poˇzadovan´a akce, aniˇz by se o tom uˇzivatel dozvˇedˇel. CSRF poskytuje zejm´ena formul´aˇre a obsluˇzn´e str´anky, kter´ ym se data pˇred´avaj´ı pomoc´ı GET parametr˚ u. Tento u ´tok je velmi nebezpeˇcn´ y, jelikoˇz se mu d´a pouze velmi tˇeˇzko zabr´anit. V dneˇsn´ı dobˇe existuje prakticky jedin´e ˇreˇsen´ı, kter´e by pokrylo cel´ y rozsah CSRF. Toto ˇreˇsen´ı je popsan´e v 8.3.4. 23
Rizika v roce 2010 podle OWASP
Security Misconfiguration Jedn´a se o bezpeˇcnostn´ı riziko, kter´e je zp˚ usobeno nedostateˇcn´ ym zabezpeˇcen´ım konfigurac´ı aplikaˇcn´ıch server˚ u, datab´azov´ ych server˚ u, softwarov´ ych platforem atd. (napˇr. ponech´an´ım v´ ychoz´ıch hodnot, neaktualizov´an´ı aj.). Mezi ˇcast´e chyby v konfiguraci patˇr´ı zejm´ena: 1. Nedefinovan´ a chybov´ a str´ anka - Standardnˇe jsou webov´e aplikace naprogramovan´e v jazyce Java nastaveny tak, aby v pˇr´ıpadˇe chyby aplikace vypisovaly do okna prohl´ıˇzeˇce cel´ y chybov´ y v´ ypis. Ten obsahuje v´ ypis vˇsech tˇr´ıd a metod, kter´e p´ad ovlivnil, vˇcetnˇe informac´ı o d˚ uvodu ´ zastaven´ı bˇehu aplikace. Utoˇcn´ık pak m˚ uˇze snadnˇeji odhalit slab´a m´ısta aplikace a vyuˇz´ıt je k pr˚ uniku. ˇ adn´a nebo nespr´avn´a 2. Nastaven´ı pˇ r´ıstupu k chr´ anˇ en´ ym zdroj˚ um - Z´ konfigurace pˇr´ıstupu ke zdroj˚ um uloˇzen´ ym na serveru aplikace (napˇr. adres´aˇri, souboru apod.). Tento probl´em je detailnˇeji pops´an v podkapitole 5.1 Failure to Restrict URL Access. 3. Nenastaven´ e SSL Secure Sockets Layer (SSL) slouˇz´ı k ˇsifrov´aln´ı komunikace mezi serverem a klientem (napˇr. webov´ ym prohl´ıˇzeˇcem). V pˇr´ıpadˇe nepouˇzit´ı t´eto metody hroz´ı odposlech komunikace, a t´ım napˇr. moˇznost kompromitace pˇrihlaˇsovac´ıch u ´daj˚ u uˇzivatel˚ u aplikace. V´ıce v 5.1 Insufficient Transport Layer Protection. 4. Nepouˇ zit´ı HttpOnly Cookies - V pˇr´ıpadˇe pouˇzit´ı HttpOnly Cookies je pˇr´ıstup ke cookies uˇzivatele povolen pouze pˇres HTTP a nen´ı je tedy moˇzn´e z´ıskat napˇr. pomoc´ı JavaScriptu (jedna z metod ochrany proti XSS, viz 5.1 Cross Site Scripting). 5. Session id jako GET parametr - V pˇr´ıpadˇe vyuˇzit´ı syst´emu pˇred´av´an´ı session id jako parametru v adresn´ı ˇr´adce (metoda GET) m˚ uˇze v´est ke snadnˇejˇs´ımu odcizen´ı relace uˇzivatele v aplikaci. Parametr GET m˚ uˇze b´ yt jako souˇc´ast URL ukl´ad´an v logovac´ıch souborech a je zjistiteln´ yi na str´ank´ach, kam uˇzivatel pozdˇeji pˇrejde pomoc´ı parametru referer, kter´ y ukazuje URL, odkud uˇzivatel str´anku aplikace navˇst´ıvil.
24
Rizika v roce 2010 podle OWASP
Insecure Cryptographic Storage Insecure Cryptographic Storage jsou rizika vypl´ yvaj´ıc´ı z nedostateˇcnˇe chr´anˇen´ ych citliv´ ych dat jako jsou napˇr. hesla, rodn´a ˇc´ısla, ˇc´ısla kreditn´ıch karet apod. Webov´e aplikace obvykle vyuˇz´ıvaj´ı kryptografick´ ych metod k ochranˇe citliv´ ych dat. C´ılem tˇechto metod je ochrana tˇechto dat v pˇr´ıpadˇe napaden´ı datab´aze ˇci jin´eho zp˚ usobu z´ısk´an´ı citliv´ ych dat. V tomto pˇr´ıpadˇe jsou data pro u ´toˇcn´ıka neˇciteln´a a je nucen pouˇz´ıt dalˇs´ı metody pro jejich rozˇsifrov´an´ı, kter´e je v mnoha pˇr´ıpadech kv˚ uli jejich algoritmick´e sloˇzitosti ˇcasovˇe velmi n´aroˇcn´e. Obvykle jsou pro ˇsifrov´an´ı pouˇzity metody jako napˇr. algoritmus MD5 (viz 4.4), SHA1, AES, RSA, SHA-256 aj.
Failure to Restrict URL Access Tento bezpeˇcnostn´ı nedostatek spoˇc´ıv´a v nedostateˇcn´em zabezpeˇcen´ı ˇr´ızen´ı pˇr´ıstupu ke zdroj˚ um informac´ı (str´anka, adres´aˇr, dokument apod.) pˇres URL. Probl´em m˚ uˇze nastat v pˇr´ıpadˇe, ˇze u ´toˇcn´ık napˇr. zjist´ı strukturu uloˇzen´ı dat v aplikaci a m˚ uˇze se pot´e dostat ke zdroj˚ um, kter´e mu nen´aleˇz´ı. Obvykle se tento pˇr´ıstup omezuje v konfiguraˇcn´ıch souborech. U webov´eho serveru Apache je to zejm´ena soubor .htaccess, u Tomcat pak web.xml nebo v pˇr´ıpadˇe vyuˇzit´ı Spring Security security.xml.
Insufficient Transport Layer Protection Jedn´a se o bezpeˇcnostn´ı rizika spojen´a s nedostateˇcn´ ym zabezpeˇcen´ım proti u ´tok˚ um, kter´e vyuˇz´ıvaj´ı odposlech˚ u s´ıtˇe. V pˇr´ıpadˇe, ˇze komunikace mezi aplikac´ı a klientem nen´ı zabezpeˇcena nˇejak´ ym ˇsifrovac´ım algoritmem, jako napˇr. Transport Layer Security zkr. TLS (resp. Secure Sockets Layer zkr. SSL), jsou data pˇren´aˇsena v jejich surov´e podobˇe a v pˇr´ıpadˇe, kdy u ´toˇcn´ık sleduje tok dat na s´ıti, m´a k tˇemto dat˚ um pˇr´ıstup, aniˇz by je musel nˇejak´ ym zp˚ usobem rozˇsifrovat.
25
Rizika v roce 2010 podle OWASP
Unvalidated Redirects and Forwards Jedn´a se o u ´tok pˇresmˇerov´an´ım na jin´e str´anky, kter´e mohou obsahovat ˇskodliv´ y k´od. Aplikace je n´achyln´a k tomuto typu u ´toku v pˇr´ıpadˇe, ˇze je v n´ı pouˇzito skript˚ u slouˇz´ıc´ıch k pˇresmˇerov´an´ı. Napˇr. http://trusted-domain/redirect.jsp?url=attackers-site Probl´em nast´av´a v pˇr´ıpadˇe, kdy aplikace nekontroluje seznam IP a dom´en, ´ cn´ık kam m˚ uˇze b´ yt uˇzivatel pomoc´ı v´ yˇse uveden´eho URL pˇresmˇerov´an. Utoˇ pak m˚ uˇze vyuˇz´ıt t´eto vlastnosti napˇr. zasl´an´ım odkazu poˇzadovan´emu uˇzivateli, kter´ y pohledem zkontroluje dom´enu str´anky a v domnˇen´ı, ˇze se jedn´a o bezpeˇcnou str´anku, odkaz otevˇre. Tento typ u ´toku je zp˚ usob jak uskuteˇcnit u ´toky jako napˇr. 5.1 - CSRF nebo instalaci ˇskodliv´eho software pˇres bezpeˇcnostn´ı chybu v prohl´ıˇzeˇci.
26
6 Mechanismy pouˇzit´e pˇri ˇreˇsen´ı autentizace a autorizace v EEG/ERP port´ alu V aplikaci je vyuˇzito technologi´ı popsan´ ych v kapitole 4
6.1
´ Urovnˇ e uˇ zivatelsk´ ych opr´ avnˇ en´ı
Uˇ zivatelsk´ a opr´ avnˇ en´ı na u ´ rovni Spring Framework Pˇr´ıstup ke skupin´am str´anek aplikace je definov´an v souboru security.xml, kter´ y je konfiguraˇcn´ım souborem frameworku Spring Security (viz 4.2). Autorizace pˇr´ıstupu k ˇc´ast´ım JSP str´anek se prov´ad´ı pˇres JSTL direktivy. Pˇr´ıklad pˇr´ıstupu pouze administr´ator˚ um a registrovan´ ym uˇzivatel˚ um: <security:authorize ifAnyGranted="ROLE_USER,ROLE_ADMIN"> Uˇzivatelsk´a opr´avnˇen´ı definovan´a ve Spring Security jsou n´asleduj´ıc´ı: • ANONYMOUS - Uˇzivatel, kter´ y navˇst´ıv´ı str´anku aplikace, ale nen´ı pˇrihl´aˇsen do syst´emu. Tento uˇzivatel m´a umoˇznˇen pouze pˇr´ıstup k registraci, pˇrihl´aˇsen´ı a obnovˇe hesla. Framework Spring Security tohoto uˇzivatele identifikuje direktivou IS_AUTHENTICATED_ANONYMOUSLY. y uˇzivatel, kter´ y m´a pˇr´ıstup k z´akladn´ım • ROLE USER - Pˇrihl´aˇsen´ funkc´ım port´alu, se kter´ ymi je asociov´an. Asociace prob´ıh´a v kontextu aplikace a je urˇcena vlastnictv´ım zdroj˚ u nebo jejich vztahu k uˇzivateli (napˇr. zdroje v´ yzkumn´e skupiny, jej´ımˇz je uˇzivatel ˇclenem). Jedn´a se zejm´ena o zdroje jako napˇr. administrace ˇcl´ank˚ u, v´ yzkumn´ ych skupin, experiment˚ u, sc´en´aˇr˚ u, ˇc´ıseln´ık˚ u a historii. Spring Security tohoto uˇzivatele identifikuje direktivou IS_AUTHENTICATED_FULLY. • ROLE ADMIN - Pˇrihl´aˇsen´ y uˇzivatel (administr´ator aplikace), kter´ y m´a pˇr´ıstup ke vˇsem zdroj˚ um, kter´e jsou v aplikaci uloˇzen´e. Tento uˇzivatel nen´ı z´avisl´ y na jeho asociaci s chr´anˇen´ ym zdrojem a je mu povolen pˇr´ıstup do cel´e aplikace vˇcetnˇe administrace veˇsker´ ych zdroj˚ u. 27
Autorizace nov´eho uˇzivatele
Tento uˇzivatel m´a nav´ıc oproti ROLE_USER moˇznost zobrazit administraci ostatn´ıch uˇzivatelsk´ ych u ´ˇct˚ u, kde je mu umoˇznˇena zmˇena jejich rol´ı v aplikaci. Tento uˇzivatel je identifikov´an direktivou ROLE_ADMIN ve Spring Security.
Uˇ zivatelsk´ a opr´ avnˇ en´ı v kontextu aplikace Aplikace prov´ad´ı autorizaci na u ´rovni pˇr´ıstupu k obsahu str´anky z pohledu kontextu aplikace. Tato autorizace je prov´adˇena v pˇr´ıpadˇe, ˇze uˇzivatel m´a povolen pˇr´ıstup k dan´e str´ance a je nutn´e ovˇeˇrit k jak´ ym zdroj˚ um na str´ance je autorizov´an pˇristupovat. Jedn´a se tedy o ˇr´ızen´ı pˇr´ıstupu uˇzivatele a nikoliv vˇsech uˇzivatel˚ u s danou u ´rovn´ı opr´avnˇen´ı definovanou ve Spring Security (viz Uˇzivatelsk´a opr´avnˇen´ı na u ´rovni Spring Framework). • Vlastn´ık zdroje - Uˇzivatel, kter´ y je vlastn´ıkem chr´anˇen´eho zdroje jako napˇr. experimentu, ˇcl´anku, v´ yzkumn´e skupiny apod. Tento uˇzivatel m´a opr´avnˇen´ı manipulovat jak se zdrojem, tak s vlastnostmi, kter´e mu n´aleˇz´ı (napˇr. ˇr´ızen´ı pˇr´ıstupu ke zdroji, jeho editace atd.). Za vlastn´ıka zdroje je povaˇzov´an i administr´ator v´ yzkumn´e skupiny. ˇ • Clen skupiny s opr´ avnˇ en´ım pˇ r´ıstupu - Uˇzivatel´e, kteˇr´ı jsou ˇclenem nˇekter´e v´ yzkumn´e skupiny, maj´ı pˇr´ıstup ke zdroj˚ um, kter´e jin´ı ˇclenov´e skupiny nastavili jako priv´atn´ı pro danou skupinu.
6.2
Autorizace nov´ eho uˇ zivatele
Uˇzivatel m˚ uˇze b´ yt do syst´emu pˇrid´an dvˇema zp˚ usoby a to tak, ˇze se do aplikace zaregistruje s´am, nebo jej pˇrid´a administr´ator. V obou pˇr´ıpadech je nutn´e vyplnit registraˇcn´ı formul´aˇr a registrovan´emu uˇzivateli je pot´e odesl´an registraˇcn´ı e-mail obsahuj´ıc´ı pˇrihlaˇsovac´ı u ´daje a odkaz, kter´ ym potvrd´ı svou registraci. Tento odkaz obsahuje jednoznaˇcn´ y identifik´ator poˇzadavku o registraci, kter´ y je vˇzdy unik´atn´ı, a nen´ı tedy moˇzn´e jej uhodnout. Tento zp˚ usob ovˇeˇrov´an´ı je pouˇzit spoleˇcnˇe s mechanismem captcha (pˇrepis n´ahodnˇe generovan´eho k´odu z obr´azku nebo audio nahr´avky) a automaticky odliˇsuje skuteˇcn´e uˇzivatele od robot˚ u (napˇr. data-mining robot˚ u z´ısk´avaj´ıc´ı data z internetov´ ych aplikac´ı). 28
7 Testov´an´ı zabezpeˇcen´ı port´alu EEG/ERP Port´al je rozs´ahl´a webov´a aplikace, kter´a se vyv´ıj´ı jiˇz nˇekolik let a neust´ale v n´ı pˇrib´ yvaj´ı nov´ı uˇzivatel´e a nov´a data. Ta mohou b´ yt citliv´a a je nutn´e je chr´anit pˇred potenci´aln´ımi u ´toˇcn´ıky. N´ıˇze je pops´ano deset nejˇcastˇejˇs´ıch bezpeˇcnostn´ıch rizik a u ´tok˚ u s nimi spojen´ ych, kter´e sestavila organizace The Open Web Application Security Project pro rok 2010. Jejich popis je uveden v kapitole 5.1.
Spoleˇ cn´ e testovac´ı prostˇ redky Testovac´ı JavaScript k´ od - Pro testovac´ı u ´ˇcely byl vytvoˇren extern´ı Javascriptov´ y k´od, na adrese http://dp.f3design.cz/xss, kter´ y obsahuje jednoduch´ y k´od: alert(document.cookie); Pˇri u ´spˇeˇsn´em proveden´ı v´ yˇse uveden´eho k´odu se objev´ı vyskakovac´ı okno s cookies, kter´e m´a uˇzivatel spojen´e s aplikac´ı. V pˇr´ıpadˇe, ˇze se zobraz´ı toto okno i s vyplnˇen´ ymi cookies, je ihned zˇrejm´e, ˇze doch´az´ı ke dvˇema pr˚ unik˚ um. Tˇemito u ´toky jsou Cross-Site Scripting (viz 5.1 XSS) a kr´adeˇz uˇzivatelsk´ ych cookies, moˇzn´a i s jeho session id (viz 5.1 Broken Authentication and Session Management). Adresa tohoto skriptu byla jeˇstˇe zkr´acena pomoc´ı veˇrejn´eho zkracovaˇce adres http://bit.ly a v´ ysledn´a adresa byla http://bit.ly/fE9e4k. T´ım doch´az´ı k vyˇsˇs´ı u ´rovni maskov´an´ı u ´toku. Pozn. Takov´yto u ´tok by byl samozˇrejmˇe ihned prozrazen, jelikoˇz je jeho v´ysledek viditeln´y uˇzivateli, kter´y str´anku s k´odem otevˇre. Jakmile ale u ´toˇcn´ık zjist´ı, zda je k´od u ´spˇeˇsn´y, m˚ uˇze jej zmˇenit a napˇr. si na pozad´ı ukl´adat data ze zobrazen´e str´anky.
JUnit testy - Pro potˇreby automatizovan´ ych test˚ u bylo vytvoˇreno jednotn´e testovac´ı rozhran´ı, kter´e vyuˇz´ıv´a moˇznost´ı Spring Frameworku testovat aplikaci pomoc´ı JUnit test˚ u. Pˇri anal´ yze zdrojov´eho k´odu a struktury pro29
Druhy u ´tok˚ u a jejich testov´an´ı na aplikaci
gramu, je ve v´ ysledku nebylo nutn´e pouˇz´ıt. Toto rozhran´ı je vˇsak vyuˇz´ıv´ano dalˇs´ımi v´ yvoj´aˇri tohoto projektu, pro jeho testov´an´ı.
7.1
Druhy u ´ tok˚ u a jejich testov´ an´ı na aplikaci
N´ıˇze je uveden v´ yˇcet testovan´ ych bezpeˇcnostn´ıch rizik a u ´tok˚ u, kde u kaˇzd´eho z nich je pops´ano, jak byla tato zranitelnost testov´ana a zda je aplikace k t´eto zranitelnosti n´achyln´a.
7.1.1
Injection (HQL Injection)
Jelikoˇz je v aplikaci EEG/ERP port´alu vyuˇzito pro komunikaci s datab´az´ı frameworku Hibernate (viz 4.3), nelze pouˇz´ıt klasick´ y pokus o SQL injection, kter´ y byl pops´an v 5.1. V pˇr´ıpadˇe pokusu o proniknut´ı objektovˇe relaˇcn´ımi frameworky se tento u ´tok naz´ yv´a ORM Injection“. V pˇr´ıpadˇe pouˇzit´ı Hi” bernate je n´azev u ´toku HQL Injection, kv˚ uli n´azvu SQL dialektu tohoto frameworku (HQL). D´ale je v aplikaci vyuˇzito pˇr´ıstupov´ ych objekt˚ u podle n´avrhov´eho vzoru DAO, kter´e jsou pouˇzity pro veˇsker´ y pˇr´ıstup k datab´azi. Vˇsechny tyto DAO objekty jsou zabezpeˇcen´e proti HQL injection. Prvn´ım druhem zabezpeˇcen´ı je vyuˇzit´ı hled´an´ı v DB pˇr´ımo pomoc´ı poˇzadovan´eho parametru. Nen´ı tedy moˇzn´e upravit dotaz tak, aby mohlo doj´ıt k u ´toku na datab´azi. Napˇr. tˇelo metody objektu DAO (PersonDao) pro vyhled´av´an´ı uˇzivatele podle jeho uˇzivatelsk´eho jm´ena: String HQLselect = "from Person person " + "where person.username = :userName"; Person foundUser = (Person) DataAccessUtils.uniqueResult( getHibernateTemplate().findByNamedParam(HQLselect, "userName", userName)); V pˇr´ıpadˇe jin´ ych vyuˇzit´ı DAO je vˇzdy jako vstupn´ı parametr objekt jiˇz pˇr´ımo vytvoˇren´ y v controlleru. Zde nen´ı moˇzn´e, aby doch´azelo k HQL injection, protoˇze parametr pot´e vstupuje do dotazu jako objekt a nikoliv jako 30
Druhy u ´tok˚ u a jejich testov´an´ı na aplikaci
text, kter´ y by mohl zmˇenit chov´an´ı dotazu. V cel´e aplikaci nen´ı na ˇza´dn´em m´ıstˇe umoˇznˇeno zas´ahnout do podoby HQL dotazu pomoc´ı uˇzivatelsk´eho vstupu. HQL Injection tedy nen´ı v aplikaci moˇzn´ y.
7.1.2
Cross-Site Scripting (XSS)
Pro testov´an´ı tohoto u ´toku bylo vyuˇzito zejm´ena skriptu uveden´eho v u ´vodu t´eto kapitoly. Vzhledem k tomu, ˇze XSS u ´tok je obt´ıˇzn´e automatizovat a pˇr´ıpadn´e nalezen´e programov´e ˇreˇsen´ı velmi ˇcasto neodpov´ıd´a poˇzadavk˚ um testov´an´ı, byla vytvoˇrena mapa str´anek, kter´e obsahuj´ı moˇznosti uˇzivatelsk´eho vstupu (viz tabulka 7.1.2). Nˇekter´e z uˇzivatelsk´ ych vstup˚ u, jako napˇr. vstupn´ı pole formul´aˇr˚ u byly limitov´any svou d´elkou. Tento probl´em m˚ uˇze jednoduˇse pˇr´ıpadn´ yu ´toˇcn´ık obej´ıt ve v´ yvoj´aˇrsk´ ych n´astroj´ıch nˇekter´ ych souˇcasn´ ych prohl´ıˇzeˇc˚ u. Napˇr. Google Chrome umoˇzn ˇuje zmˇenit k´od str´anky bez nutnosti jej´ıho obnoven´ı. Tento druh u ´toku je v aplikaci automaticky blokov´an1 .
Druhy testovan´ ych XSS u ´ tok˚ u Zp˚ usob˚ u, jak prov´est testov´an´ı XSS u ´toku na aplikaci, je nˇekolik: ´ cn´ık si vybere zraniteln´e Non-persistent XSS - Doˇ casn´ y XSS - Utoˇ m´ısto na internetov´e str´ance, na kter´e chce prov´est u ´tok. Zpravidla se jedn´a o m´ısta, kde je generov´an text na str´ance podle zadan´e URL. Uˇzivatel je tedy ohroˇzen, pokud se u ´toˇcn´ıkovi povede donutit ho otevˇr´ıt u ´toˇcn´ıkem upraven´ y odkaz, kter´ y m˚ uˇze b´ yt jeˇstˇe zak´odovan´ y jako k´odov´e oznaˇcen´ı html entitn´ıch znak˚ u. V naˇsem pˇr´ıpadˇe napˇr. http://URL/stranka?captcha="><script>alert(’XSS’) provede ukonˇcen´ı objektu pro captcha2 na str´ance a za nˇej bude 1
Aplikace EEG/ERP port´ alu m´ a vˇsechny d´elky vstup˚ u oˇsetˇren´e nejen na stranˇe klienta (ve formul´ aˇr´ıch), ale i na stranˇe serveru (v controllerech). 2 Captcha je obecnˇe pouˇz´ıvan´ y Turing˚ uv test pro odliˇsen´ı uˇzivatele od robot˚ u. Ovˇeˇrov´an´ı prob´ıh´ a pˇreps´ an´ım textu nebo vyˇreˇsen´ım jednoduch´e u ´lohy.
31
Druhy u ´tok˚ u a jejich testov´an´ı na aplikaci
um´ıstˇen ˇskodliv´ y k´od, kter´ y vyp´ıˇse XSS, znaˇc´ıc´ı u ´spˇeˇsn´ yu ´tok. Tento zp˚ usob byl ne´ uspˇeˇsn´ y, protoˇze funguje pouze v pˇr´ıpadˇe, ˇze je generov´an HTML k´od str´anky z parametr˚ u uveden´ ych v URL a tehdy, kdyˇz u ´toˇcn´ık v´ı, zda pr´avˇe dan´ y parametr zp˚ usobuje XSS pr˚ unik. V naˇsem pˇr´ıpadˇe ˇz´adn´a str´anka nem´a obsah generov´an pomoc´ı GET parametr˚ u.
Persistent XSS - Trval´ y XSS - Persistent XSS je velmi podobn´ y NonPersistent u ´toku s t´ım rozd´ılem, ˇze uˇzivatel nemus´ı otevˇr´ıt odkaz, kter´ y mu pˇripravil u ´toˇcn´ık, jelikoˇz v tomto pˇr´ıpadˇe jsou ˇskodliv´ ym k´odem data, kter´a ´ cn´ıkovi se jiˇz podaˇrilo uloˇzit jsou uloˇzena v aplikaci (napˇr. v datab´azi). Utoˇ k´od do aplikace a t´ım p´adem je automaticky vkl´ad´an do obsahu zobrazovan´e str´anky a uˇzivatel se o tom pravdˇepodobnˇe ani nedozv´ı. ´ Ukolem u ´toˇcn´ıka je tedy vyhledat zraniteln´e m´ısto v aplikaci, kter´e nem´a oˇsetˇren´e vkl´ad´an´ı HTML tag˚ u a doufat, ˇze m´ısto, kde je realizov´ano jejich n´asledn´e vypisov´an´ı, nen´ı pˇrev´adˇeno a interpretov´ano jako obyˇcejn´ y text. Tento zp˚ usob u ´toku byl u ´spˇeˇsn´ y na nˇekolika str´ank´ach aplikace (viz tabulka 7.1.2).
DOM Based XSS DOM-Based u ´tok je unik´atn´ı formou XSS u ´toku, jelikoˇz skript nemus´ı b´ yt nutnˇe vyps´an na str´ance, aby byl vyuˇzit uˇzivatel˚ um ´ prohl´ıˇzeˇc k jeho interpretaci. Utok spoˇc´ıv´a ve vyuˇzit´ı schopnosti souˇcasn´ ych prohl´ıˇzeˇc˚ u interpretovat text zadan´ y do adresn´ıho ˇr´adku jako javascript. Tedy i napˇr. javascript:alert("XSS"); zapsan´ y jako adresa, je interpretov´an jako JS a zobraz´ı okno s n´apisem XSS. T´eto moˇznosti se vyuˇz´ıv´a napˇr. podvrˇzen´ım skriptu jako n´azvu kotev na str´ance apod. Tento zp˚ usob u ´toku byl u ´spˇeˇsn´ y na vˇsech str´ank´ach aplikace. Vzhledem k tomu, ˇze se jedn´a o hrozbu pouze v pˇr´ıpadˇe, kdy by uˇzivatel vloˇzil javascript pˇr´ımo do adresn´ıho ˇr´adku, je moˇzn´e tuto zranitelnost povaˇzovat jako akceptovatelnou v pˇr´ıpadˇe vyuˇzit´ı ochrann´ ych mechanism˚ u zm´ınˇen´ ych v kapitole 8.
Zraniteln´ e ANO ANO NE ANO NE ANO ANO NE NE NE NE NE NE NE NE NE ANO ANO NE NE NE NE NE NE NE NE NE NE NE NE NE
*
*
* * * * * * * *
Tabulka 7.1: Tabulka str´anek s uˇzivatelsk´ ymi vstupy a jejich n´achylnost´ı na XSS (znak * znaˇc´ı omezenou d´elku uˇzivatelsk´eho vstupu)
33
Druhy u ´tok˚ u a jejich testov´an´ı na aplikaci
7.1.3
Broken Authentication and Session Management
Podle OWASP je pro dos´ahnut´ı vyˇsˇs´ı ochrany dat doporuˇceno [7] drˇzet se n´ıˇze uveden´ ych doporuˇcen´ı. Tato doporuˇcen´ı jsou urˇcena jak pro syst´emov´e administr´atory, tak pro uˇzivatele syst´emu. • S´ıla hesla - V pˇr´ıpadˇe EEG/ERP port´alu nen´ı s´ıla hesla nijak kontrolov´ana a je pouze na uˇzivateli, jak siln´e heslo si zvol´ı. Obecnˇe je doporuˇcov´ano vyuˇz´ıv´an´ı speci´aln´ıch znak˚ u a ˇc´ıslic. D´ale je doporuˇceno omezit minim´aln´ı d´elku hesla. • Omezen´ı poˇ ctu pˇ rihl´ aˇ sen´ı - Kv˚ uli ochranˇe pˇred brute-force3 u ´tokem nebo jin´ ym systematick´ ym u ´tokem (napˇr. pouˇzit´ım slovn´ıku s hesly), je dobr´e ˇcasovˇe omezit intervaly mezi pˇrihl´aˇsen´ımi. T´ım doch´az´ı k v´ yrazn´emu odd´alen´ı u ´spˇechu u ´toku a odrazen´ı u ´toˇcn´ıka. Dalˇs´ı variac´ı tohoto obrann´eho mechanismu m˚ uˇze b´ yt napˇr. omezen´ı poˇctu pˇrihl´aˇsen´ı za jednotku ˇcasu (napˇr. 10 ne´ uspˇeˇsn´ ych pˇrihl´aˇsen´ı a pot´e 10 minut z´akaz pˇrihl´aˇsen´ı). V port´alu tento probl´em nen´ı nijak ˇreˇsen a u ´toˇcn´ık je limitov´an pouze ˇcasov´ ym intervalem odpovˇed´ı serveru, zda bylo pˇrihl´aˇsen´ı u ´spˇeˇsn´e ˇci ´ cn´ık je v naˇsem pˇr´ıpadˇe tak´e limitov´an t´ım, ˇze je nucen nikoliv. Utoˇ nejprve zjistit pˇrihlaˇsovac´ı jm´eno nˇekter´eho z uˇzivatel˚ u a aˇz pot´e se m˚ uˇze pokusit uhodnout heslo. Pokusit se uhodnout obˇe tyto n´aleˇzitosti je nere´aln´e vzhledem k ˇcasov´e n´aroˇcnosti brute-force. • Kontrola zmˇ eny hesla - V pˇr´ıpadˇe, ˇze uˇzivatel poˇzaduje zmˇenu hesla, je nutn´e nejprve zadat heslo p˚ uvodn´ı. T´ımto doch´az´ı k ochranˇe proti zmˇenˇe uˇzivatelsk´eho hesla napˇr. v pˇr´ıpadˇe odcizen´ı session id (viz Session Hijacking) nebo jin´ ych zp˚ usob˚ u z´ısk´an´ı identity jin´eho uˇzivatele. Toto doporuˇcen´ı je tedy dodrˇzeno. ˇ adn´e uˇzivatelsk´e heslo nen´ı v datab´azi ani • Uloˇ zen´ı hesla v DB - Z´ jinde uloˇzeno jako prost´ y text. Ukl´ad´a se pouze jeho hash otisk, kter´ y je vytvoˇren pomoc´ı algoritmu MD5 (viz 4.4). Pˇri pˇrihl´aˇsen´ı uˇzivatele se zad´av´an´e heslo opˇet zak´oduje t´ımto algoritmem a porovn´avaj´ı se 3
Brute-force neboli u ´tok hrubou silou je u ´tok, kdy se u ´toˇcn´ık snaˇz´ı prolomit zabezpeˇcen´ı systematick´ ym proch´ azen´ım cel´eho prostoru ˇreˇsen´ı. Tedy zkouˇsen´ım hesel vygenerovan´ ych ze vˇsech moˇzn´ ych kombinac´ı zadan´ ych znak˚ u podle poˇzadovan´e d´elky.
34
Druhy u ´tok˚ u a jejich testov´an´ı na aplikaci
hash otisky tˇechto hesel. V pˇr´ıpadˇe, ˇze otisky souhlas´ı, jedn´a se z´aroveˇ n 4 o shodu hesel . • Ochrana pˇ rihlaˇ sovac´ıch u ´ daj˚ u pˇ ri pˇ rihlaˇ sov´ an´ı - Data pˇri odesl´an´ı pˇrihlaˇsovac´ıho formul´aˇre nejsou nijak chr´anˇena. Jedinou ochranou je jejich pos´ıl´an´ı metodou POST, kde pˇrihlaˇsovac´ı u ´daje nejsou vidˇet pˇr´ımo v parametrech adresy v adresn´ım ˇra´dku, jako je tomu u metody GET. Odes´ıl´an´ı pˇrihlaˇsovac´ıch u ´daj˚ u je tedy n´achyln´e k odposlechu, v pˇr´ıpadˇe, ˇze by u ´toˇcn´ık monitoroval komunikaci mezi klientem a serverem.
Session Hijacking Ukraden´ı relace, neboli Session Hijacking je u ´tok, kdy u ´toˇcn´ık jiˇz zn´a session id jin´eho, pr´avˇe pˇrihl´aˇsen´eho uˇzivatele (mohl ho z´ıskat napˇr. pomoc´ı 5.1 XSS). Naˇse aplikace nen´ı odoln´a proti tomuto u ´toku a v pˇr´ıpadˇe nastaven´ı cookie se session id nˇejak´eho jin´eho uˇzivatele, je u ´toˇcn´ık pˇrihl´aˇsen jako tento uˇzivatel vˇcetnˇe u ´rovnˇe jeho opr´avnˇen´ı.
Session Fixation Session Fixation je u ´tok, kdy u ´toˇcn´ık vloˇz´ı sv´e session id do cookies uˇzivatele a ˇcek´a na jeho pˇrihl´aˇsen´ı do aplikace. V pˇr´ıpadˇe, ˇze se uˇzivatel pˇrihl´as´ı, m˚ uˇze doj´ıt u nˇekter´ ych syst´em˚ u k asociaci vloˇzen´eho session id s u ´ˇctem ´ cn´ık je n´aslednˇe po obnoven´ı str´anky pˇripr´avˇe pˇrihl´aˇsen´eho uˇzivatele. Utoˇ hl´aˇsen jako napaden´ y uˇzivatel. V EEG/ERP port´alu nen´ı Session Fixation moˇzn´e, kv˚ uli direktivˇe zabezpeˇcovac´ıho frameworku Spring Security: <session-management session-fixation-protection="newSession"/> Ta m´a za d˚ usledek skuteˇcnost, ˇze v pˇr´ıpadˇe nov´eho pˇrihl´aˇsen´ı uˇzivatele, se vˇzdy vygeneruje nov´a relace a s n´ı i nov´e session id. Probl´emem tohoto 4
Toto nen´ı vˇzdy pravda. U hashovac´ıch funkc´ı jako napˇr. MD5 a SHA-1, je moˇzn´e naj´ıt v´ıce ˇretˇezc˚ u, u kter´ ych je jejich otisk, vytvoˇren´ y pomoc´ı tˇechto algoritm˚ u, shodn´ y (v´ıce informac´ı v [5]).
35
Druhy u ´tok˚ u a jejich testov´an´ı na aplikaci
ˇreˇsen´ı je fakt, ˇze v pˇr´ıpadˇe vytvoˇren´ı nov´e relace se nepˇren´aˇsej´ı promˇenn´e relace st´avaj´ıc´ı. V naˇsem pˇr´ıpadˇe je vˇsak tento probl´em akceptovateln´ y, jelikoˇz sessions se v aplikaci vyuˇz´ıvaj´ı jen zˇr´ıdka a neslouˇz´ı k udrˇzen´ı informac´ı po celou dobu relace (pouze napˇr. v HTML formul´aˇr´ıch apod.).
7.1.4
Insecure Direct Object References
Aplikace byla otestov´ana na tento druh u ´toku na vˇsech URL, kter´e pˇrej´ımaj´ı parametr pro zobrazen´ı str´anky a jejich obsah by mˇel b´ yt omezen pouze pro nˇekter´e uˇzivatele. Po proveden´ı test˚ u bylo nalezeno nˇekolik bezpeˇcnostn´ıch nedostatk˚ u. • Redakˇ cn´ı syst´ em (articles) – Uˇzivatel m´a moˇznost pˇrihl´asit se k odbˇeru ˇcl´ank˚ u v´ yzkumn´e skupiny i v pˇr´ıpadˇe, ˇze nen´ı jej´ım ˇclenem. – Je moˇzn´e se pˇrihl´asit k odbˇeru koment´aˇr˚ u u ˇcl´ank˚ u, ke kter´ ym uˇzivatel nem´a pˇr´ıstup. – Je umoˇznˇeno zobrazit libovoln´ y ˇcl´anek, pokud uˇzivatel zn´a jeho ID, i v pˇr´ıpadˇe, ˇze k nˇemu nemˇel b´ yt uˇzivateli povolen pˇr´ıstup. • Experimenty (experiments) – V pˇr´ıpadˇe, ˇze uˇzivatel pouˇzije ID experimentu, ke kter´emu nem´a pˇr´ıstup, je mu zobrazen stejn´ ym zp˚ usobem, jako bˇeˇzn´ y experiment, ke kter´emu m´a pˇr´ıstup povolen. – Editaˇcn´ı formul´aˇr experimentu je viditeln´ y i pro uˇzivatele, kteˇr´ı k nˇemu nemaj´ı povolen pˇr´ıstup. Tento formul´aˇr nejde odeslat, ale obsahuje v´ıce detailn´ıch informac´ı, neˇz je viditeln´e z obsahu str´anek, ke kter´ ym maj´ı pˇr´ıstup i uˇzivatel´e s niˇzˇs´ımi opr´avnˇen´ımi. • Sc´ en´ aˇ re (scenarios) – Uˇzivateli je umoˇznˇeno zobrazit libovoln´ y sc´en´aˇr, i kdyˇz k nˇemu nem´a povolen pˇr´ıstup. V aplikaci bylo nalezeno nˇekolik bezpeˇcnostn´ıch nedostatk˚ u, a je tedy n´achyln´a k tomuto druhu u ´toku. 36
Druhy u ´tok˚ u a jejich testov´an´ı na aplikaci
7.1.5
Cross Site Request Forgery
Pro testovac´ı u ´ˇcely byla vytvoˇrena jednoduch´a str´anka na dom´enˇe odliˇsn´e od dom´en, na kter´ ych je nyn´ı nasazena aplikace. Tato str´anka obsahovala iframe s obsahem str´anky, kter´a obsluhuje smaz´an´ı pˇr´ıspˇevku v redakˇcn´ım syst´emu port´alu. <iframe src="http://147.228.64.173:8080/EEGDatabase/ articles/delete.html?articleId=37" /> Pot´e byl v prohl´ıˇzeˇci pˇrihl´aˇsen uˇzivatel, kter´ y m´a v aplikaci pr´ava smazat tento pˇr´ıspˇevek. V okamˇziku, kdy uˇzivatel otevˇrel str´anku s t´ımto iframe, doˇslo z´aroveˇ n k otevˇren´ı str´anky v tomto r´amci a z´aroveˇ n k jeho automatick´emu pˇrihl´aˇsen´ı (z d˚ uvodu ovˇeˇrov´an´ı pomoc´ı session, kter´a je v danou chv´ıli platn´a), ovˇeˇren´ı jeho pr´av a n´asledn´eho smaz´an´ı poˇzadovan´eho pˇr´ıspˇevku. ˇ sen´ı se kv˚ Port´al je tedy n´achyln´ y k CSRF u ´tok˚ um. Reˇ uli jeho sloˇzitosti neimplementovalo a je pops´ano d´ale v 8.3.4.
7.1.6
Security Misconfiguration
Tato bezpeˇcnostn´ı chyba se t´ yk´a zejm´ena konfigurace soubor˚ u web.xml a security.xml, kde jejich chybn´e nastaven´ı m˚ uˇze zp˚ usobit pr˚ unik do syst´emu nebo usnadnˇen´ı odhalen´ı jin´ ych bezpeˇcnostn´ıch chyb v aplikaci. Velmi ˇcast´ ymi nedostatky konfigurace aplikace jsou: 1. Nedefinovan´ a chybov´ a str´ anka - V aplikaci je pouˇzita vlastn´ı chybov´a str´anka, kter´a skr´ yv´a chybov´ y v´ ypis a zobrazuje informaˇcn´ı text ”Application error occured”. Aplikace tedy neukazuje potenci´aln´ımu u ´toˇcn´ıkovi chybov´ y v´ ypis, kter´ y by mohl v´ezt k odhalen´ı bezpeˇcnostn´ıch nedostatk˚ u. 2. Nastaven´ı pˇ r´ıstupu k chr´ anˇ en´ ym zdroj˚ um - Aplikace omezuje pˇr´ıstup k chr´anˇen´ ym zdroj˚ um - viz 7.1.8. 3. Nenastaven´ e SSL - V aplikaci nen´ı nastaven´e ˇsifrov´an´ı s vyuˇzit´ım protokolu SSL (resp. https) a je tedy moˇzn´e odposlouch´avat s´ıt’ovou komunikaci. 37
Druhy u ´tok˚ u a jejich testov´an´ı na aplikaci
4. Nepouˇ zit´ı HttpOnly Cookies - EEG/ERP port´al nevyuˇz´ıv´a HttpOnly Cookies a je tedy moˇzn´e pˇreˇc´ıst uˇzivatelsk´e cookies pomoc´ı JavaScriptu. 5. Session id jako GET parametr - Aplikace ukl´ad´a session id v cookies a nen´ı tedy moˇzn´e jej pˇreˇc´ıst v URL v adresn´ım ˇra´dku, logovac´ıch souborech, referer parametru apod.
7.1.7
Insecure Cryptographic Storage
V aplikaci EEG/ERP port´alu je pouˇzita funkce MD5 (viz 4.4) pro ukl´ad´an´ı hesel do datab´aze a pˇri pˇrihl´aˇsen´ı uˇzivatele je ze zadan´eho hesla vytvoˇren MD5 otisk , kter´ y je porovn´an se z´aznamem uloˇzen´ ym v datab´azi. MD5 v souˇcasn´e dobˇe nen´ı povaˇzov´an za bezpeˇcn´ y algoritmus k ˇsifrov´an´ı pˇrihlaˇsovac´ıch u ´daj˚ u, jelikoˇz je moˇzn´e nal´ezt v´ıce stejn´ ych MD5 otisk˚ u pro r˚ uzn´e vstupn´ı ˇretˇezce (viz [5]).
7.1.8
Failure to Restrict URL Access
Pˇr´ıstupy k URL jsou dostateˇcnˇe zabezpeˇceny d´ıky mechanism˚ um Spring Security (Viz 4.2). Jedn´a se zejm´ena o zabezpeˇcen´ı pˇr´ıstupu k adres´aˇr˚ um a str´ank´am aplikace obsahuj´ıc´ı chr´anˇen´e zdroje. V aplikaci jsou pouˇzity tˇri zabezpeˇcovac´ı direktivy: 1. IS_AUTHENTICATED_ANONYMOUSLY - Pˇr´ıstup je povolen vˇsem uˇzivatel˚ um. 2. IS_AUTHENTICATED_FULLY - Pˇr´ıstup je povolen pouze pˇrihl´aˇsen´ ym uˇzivatel˚ um a administr´ator˚ um. 3. ROLE_ADMIN - Pˇr´ıstup je povolen pouze administr´ator˚ um. Pˇr´ıklad nastaven´ı pˇr´ıstupu v souboru security.xml: 38
Druhy u ´tok˚ u a jejich testov´an´ı na aplikaci
... ...
7.1.9
Insufficient Transport Layer Protection
Aplikace nem´a k dispozici zabezpeˇcen´e pˇripojen´ı, jelikoˇz server, na kter´em je aplikace spuˇstˇena, nepodporuje zabezpeˇcen´ı pomoc´ı SSL. Komunikace je tedy vedena pˇres protokol http nam´ısto zabezpeˇcen´eho protokolu https. Potenci´aln´ı u ´toˇcn´ık m´a tedy moˇznost odposlouch´avat data pˇri komunikaci v jejich nezmˇenˇen´e podobˇe. Aplikace tedy nen´ı v tomto smˇeru nijak zabezpeˇcena.
7.1.10
Unvalidated Redirects and Forwards
Aplikace je spustiteln´a na r˚ uzn´ ych serverech, tedy i dom´en´ach, bez vˇetˇs´ıch z´asah˚ u do jej´ıho k´odu, jelikoˇz veˇsker´e adresov´an´ı je relativn´ı v˚ uˇci adrese nastaven´e v konfiguraˇcn´ım souborech. Aplikace nepouˇz´ıv´a ˇz´adn´e pˇresmˇerov´an´ı mimo str´anek EEG/ERP port´alu a extern´ıho autentizaˇcn´ıho poskytovatele Facebook.com, a aplikace tedy nen´ı n´achyln´a k tomuto typu u ´toku.
39
´ 8 Upravy autentizaˇ cn´ıch a autorizaˇ cn´ıch mechanism˚ u Vzhledem k tomu, ˇze byly nalezeny bezpeˇcnostn´ı nedostatky v autentizaˇcn´ıch a autorizaˇcn´ıch mechanismech aplikace, kter´e byly odhalen´e testov´an´ım bezpeˇcnostn´ıch rizik zm´ınˇen´ ych v kapitole 7, byla nutn´e proveden´ı jejich u ´prav. Kromˇe u ´pravy st´avaj´ıc´ıch mechanism˚ u bylo jejich ˇreˇsen´ı rozˇs´ıˇreno o autentizaci extern´ım autentizaˇcn´ım poskytovatelem Facebook.com, jehoˇz rozhran´ı pro tento mechanismus se naz´ yv´a Facebook Connect.
V kapitole 2 bylo zm´ınˇeno nˇekolik zp˚ usob˚ u autentizace. V aplikaci bylo jiˇz dˇr´ıve moˇzn´e pˇrihlaˇsovat uˇzivatele pomoc´ı bˇeˇzn´eho HTML formul´aˇre. Vzhledem k neust´al´emu n´ar˚ ustu z´ajmu o aplikaci bylo vhodn´e implementovat jednoduˇsˇs´ı mechanismus pˇrihlaˇsov´an´ı, a to s vyuˇzit´ım extern´ıho autentizaˇcn´ıho poskytovatele. S pˇrihl´ednut´ım na svˇetov´e trendy byli zvaˇzov´ani tito extern´ı autentizaˇcn´ı poskytovatel´e: • Facebook.com - Pˇrihlaˇsov´an´ı k Facebooku prob´ıh´a pomoc´ı autentizaˇcn´ıho mechanismu OAuth 2.0 a z´aroveˇ n poskytuje i moˇznost vyuˇz´ıt profil uˇzivatele jako OpenID identitu. Uˇzivatel´e v t´eto s´ıti jsou pˇri registraci nuceni vyplnit podobn´e u ´daje jako v naˇs´ı aplikaci a administr´atoˇri serveru se neust´ale snaˇz´ı o pr˚ ubˇeˇznou kontrolu pravosti tˇechto u ´daj˚ u. • Twitter.com - Tento server poskytuje moˇznost autentizace uˇzivatele pomoc´ı OAuth 1.0 a neumoˇzn ˇuje vyuˇz´ıt uˇzivatelsk´ yu ´ˇcet jako OpenID identitu. Twitter tak´e pˇri registraci poˇzaduje pouze pˇrihlaˇsovac´ı jm´eno a heslo • Google.com - Google poskytuje moˇznost pouˇz´ıt uˇzivatelsk´ y profil jako OpenID identitu a komunikovat s jeho servery je moˇzn´e pˇres obˇe verze OAuth autentizaˇcn´ıho protokolu. Probl´emem je, ˇze pˇri registraci jsou 40
Extern´ı autentizaˇcn´ı poskytovatel Facebook Connect uˇzivatel´e nuceni zad´avat pouze z´akladn´ı u ´daje. Google umoˇzn ˇuje uˇzivateli vyplnit sv˚ uj profil velmi detailnˇe, ale pouze po registraci. Uˇzivatel si str´anku s profilem mus´ı n´aslednˇe vyhledat a pot´e teprve upravit (jedn´a se o adresu http://profiles.google.com). Ve v´ ysledku byl jako extern´ı autentizaˇcn´ı poskytovatel zvolen Facebook.com, a to z n´asleduj´ıc´ıch d˚ uvod˚ u: 1. Pˇri registraci uˇzivatel´e vyplˇ nuj´ı takˇrka totoˇzn´e u ´daje jako pˇri registraci do EEG/ERP port´alu (s v´ yj´ımkou uˇzivatelsk´eho jm´ena). Je tedy moˇzn´e uˇzivatele do aplikace zaregistrovat, aniˇz by byl nucen vyplˇ novat dodateˇcn´e u ´daje. 2. Facebook o uˇzivateli ukl´ad´a velk´e mnoˇzstv´ı informac´ı, kter´e je moˇzn´e pozdˇeji v aplikaci vyuˇz´ıt. 3. Uˇzivatel´e tuto sluˇzbu vyuˇz´ıvaj´ı obvykle pravidelnˇe, a profil tak z´ısk´av´a vyˇsˇs´ı m´ıru d˚ uvˇeryhodnosti. 4. Facebook je velmi rozˇs´ıˇren v zem´ıch potenci´aln´ıch z´akazn´ık˚ u, resp. potenci´aln´ıch budouc´ıch uˇzivatel˚ u EEG/ERP port´alu. 5. Twitter neposkytuje takov´e mnoˇzstv´ı informac´ı o uˇzivateli jako Facebook nebo Google. Z´aroveˇ n m´a z tˇechto tˇr´ı poskytovatel˚ u nejniˇzˇs´ı n´aroky na u ´daje pˇri registraci uˇzivatele. 6. Google poskytuje detailn´ı informace o uˇzivateli. Ty jsou vˇsak zad´av´any na separ´atn´ı str´ance, kterou uˇzivatel nemus´ı zn´at a nen´ı povinen je vyplnit. Facebook byl vyhodnocen jako vhodn´ y pro naˇs´ı aplikaci a postup integrace s jeho API je pops´an v n´asleduj´ıc´ıch podkapitol´ach.
8.1.1
Aplikace na Facebook.com
Aby bylo moˇzn´e vyuˇz´ıvat sluˇzbu Facebook Connect, je nutn´e, aby aplikace byla zaregistrov´ana na adrese apps.facebook.com, kter´a je z´aroveˇ n registrem vˇsech aplikac´ı, kter´e jsou na Facebooku registrov´any. Po registraci kaˇzd´a Facebook aplikace dostane pˇridˇeleny n´asleduj´ıc´ı u ´daje, kter´e se pouˇz´ıvaj´ı d´ale v komunikaci mezi poskytovatelem a klientovou aplikac´ı: 41
• App ID - Jednoznaˇcn´ y identifik´ator aplikace. • App Secret - Tajn´ y ˇretˇezec, kter´ ym se aplikace identifikuje pˇri poˇzadavku na vytvoˇren´ı autentizaˇcn´ıho tokenu (podrobnˇeji v 8.1.3). D´ale je administr´ator aplikace povinen vyplnit n´azev aplikace, Canvas URL a URL serveru, na kter´em je aplikace spuˇstˇena. URL aplikace je vyplnˇena kv˚ uli ochranˇe v pˇr´ıpadˇe odcizen´ı u ´daje App Secret1 . Canvas page je URL, kter´a se naˇcte v pˇr´ıpadˇe, ˇze uˇzivatel vstoup´ı na str´anku aplikace pˇr´ımo na Facebook.com (v naˇsem pˇr´ıpadˇe je jej´ı obsah nastaven na iframe, jehoˇz obsahem je domovsk´a str´anka aplikace na serveru, ke kter´emu je aplikace asociov´ana). Pro potˇreby aplikace byly vytvoˇreny tˇri aplikace na apps.facebook.com. 1. V´ yvojov´ a aplikace (localhost) - Aplikace vytvoˇren´a pro testovac´ı a lad´ıc´ı u ´ˇcely ve f´azi v´ yvoje. Pouˇz´ıv´a se pro server pˇr´ımo u v´ yvoj´aˇre (localhost). • N´ azev: EEG/ERP Portal (localhost) • App ID: 134626213275344 • API Key: ddfd5506f5b7efe174b1549c3b0b56d2 • App Secret: a0e3aecb5b427******bb9ac52542035 • Site URL: http://localhost:8080/EEGDatabase/ • Canvas page: https://apps.facebook.com/eeg-database/ 2. Testovac´ı aplikace (veˇ rejn´ y server) - Aplikace slouˇz´ıc´ı ke zjiˇst’ov´an´ı chyb a pro testovac´ı u ´ˇcely pˇred ofici´aln´ım vyd´an´ım nov´e verze na release server, kde jsou jiˇz re´aln´a data. • N´ azev: EEG/ERP Portal (testing server) • App ID: 218187598193669 • API Key: 91f5611d4197823a0b3ed532f2c77833 • App Secret: deef9984407******b8f2ee635e47a0b • Site URL: http://uu404p03-kiv.fav.zcu.cz:8080/EEGDatabase/ • Canvas page: https://apps.facebook.com/eeg-database-test/ 1
Facebook neumoˇzn ˇuje vol´ an´ı API z jin´e dom´eny, neˇz z t´e uveden´e v administraci aplikace.
3. Release aplikace (release server) • N´ azev: EEG/ERP Portal • App ID: 187032288016286 • API Key: 212e305d965c6765371d4043746be8b0 • App Secret: 5cfe989052******7822787c80da773 • Site URL: http://eegdatabase.kiv.zcu.cz/ • Canvas page: https://apps.facebook.com/eeg-database/ Pro potˇreby komunikace s poskytovatelem je nutn´e v aplikaci udrˇzovat parametry App ID a App Secret. Tyto u ´daje jsou spoleˇcnˇe s adresou pro pˇresmˇerov´an´ı zpˇet do aplikace uloˇzeny v konfiguraˇcn´ım souboru facebook.properties.
8.1.2
´ Uprava datab´ aze
Pˇred zaˇca´tkem integrace autentizace pomoc´ı Facebook Connect bylo nutn´e upravit st´avaj´ıc´ı datab´azi tak, aby bylo moˇzn´e uloˇzit jednoznaˇcn´ y identifik´ator uˇzivatele poskytnut´ y Facebook.com. Tento identifik´ator je vˇzdy celoˇc´ıseln´ y typ, kter´ y nen´ı podle specifikace poskytovatele omezen maxim´aln´ı hodnotou. Pro potˇreby aplikace byla v datab´azi upravena tabulka PERSON, do kter´e byl pˇrid´an parametr FB_UID typu number. V pˇr´ıpadˇe, ˇze uˇzivatel nem´a sv˚ uj u ´ˇcet propojen´ y s Facebookem, je tato hodnota null. V aplikaci je pak tedy zˇrejm´e, zda uˇzivatel jiˇz m´a sv˚ uj u ´ˇcet propojen. V pˇr´ıpadˇe, ˇze ano, je uˇzivatel pˇrihl´aˇsen, v jin´em pˇr´ıpadˇe doch´az´ı k registraci nebo poˇzadavku o propojen´ı u ´ˇct˚ u v uˇzivatelsk´em nastaven´ı (viz Ovˇeˇrovac´ı mechanismus s vyuˇzit´ım OAuth 2.0).
8.1.3
Ovˇ eˇ rovac´ı mechanismus s vyuˇ zit´ım OAuth 2.0
Ovˇeˇrovac´ı mechanismus je velmi podobn´ y mechanismu na obr. 2.1 s t´ım rozd´ılem, ˇze Facebook vyuˇz´ıv´a novˇejˇs´ı verze OAuth mechanismu. Jedn´a se o verzi 2.0, kter´a se od prvn´ı verze liˇs´ı v nˇekolika bodech. 1. Uˇzivatel otevˇre str´anku aplikace a pomoc´ı tlaˇc´ıtka Facebook login spust´ı autentizaˇcn´ı proces pˇresmˇerov´an´ım na obsluˇznou str´anku apli43
kace (EEGdatabase/social/login.html). 2. Na t´eto adrese se nach´az´ı pr´azdn´a str´anka, jej´ıˇz kontroler vytvoˇr´ı poskytovatelem definovan´ y tvar URL a pˇresmˇerov´an´ım na toto URL vyˇsle poˇzadavek k autentizaci na server poskytovatele. V pˇr´ıpadˇe testovac´ı aplikace pro localhost je tvar t´eto adresy n´asleduj´ıc´ı: https://graph.facebook.com/oauth/authorize ?client_id=134626213275344 &display=page &redirect_uri=http://localhost:8080/EEGDatabase/social/user.html &scope=email,user_birthday Pole client_id je ID aplikace pˇridˇelen´e Facebookem, redirect_uri je adresa, na kterou se m´a vr´atit v´ ysledek autentizace. Pole scope urˇcuje u ´roveˇ n pˇr´ıstupu k uˇzivatelsk´ ym informac´ım. V aplikaci je potˇrebn´e vyuˇzit´ı z´akladn´ıch u ´daj˚ u (kromˇe jm´ena, pˇr´ıjmen´ı apod. poskytuje Facebook nav´ıc u ´daj o pohlav´ı), kter´e jsou poskytov´any automaticky i bez tohoto parametru. K nim je potˇreba z´ıskat uˇzivatel˚ uv email a datum 2 jeho narozen´ı . Formul´aˇr, kter´ y je zobrazen´ y uˇzivateli, obsahuje detailnˇe rozepsan´e parametry, kter´e budou aplikac´ı pouˇzity (viz obr. 8.1). 3. V pˇr´ıpadˇe, ˇze uˇzivatel schv´alil pouˇzit´ı poˇzadovan´ ych u ´daj˚ u, je poˇzadavek opˇet pˇresmˇerov´an zpˇet na str´anku aplikace, kter´a byla definov´ana jako parametr redirect_uri. Spoleˇcnˇe s pˇresmˇerov´an´ım je odesl´an unik´atn´ı doˇcasn´ y k´od code ve tvaru ˇretˇezce. 4. Aplikace pouˇzije code k sestaven´ı nov´eho URL, na kter´e bude poˇzadavek d´ale pˇresmˇerov´an. Tvar tohoto URL je napˇr. n´asleduj´ıc´ı: https://graph.facebook.com/oauth/access_token ?client_id=134626213275344 &redirect_uri=http://localhost:8080/EEGDatabase/social/user.html &client_secret=a0e3aecb5b427******bb9ac52542035 &code=5ejVbcCbI3kt ... F2zlMV3JztEStH3fAieg 2
Vˇsechna tato data jsou pˇri registraci na Facebook povinn´a, a proto je lze naj´ıt ve vˇsech uˇzivatelsk´ ych profilech.
Obr´azek 8.1: Poˇzadavek aplikace pro pˇr´ıstup k uˇzivatelsk´emu profilu 5. Po pˇresmˇerov´an´ı na tuto adresu Facebook ovˇeˇr´ı, zda poˇzadavek pˇriˇsel ze spr´avn´e aplikace t´ım, ˇze zkontroluje ID aplikace, dˇr´ıve pˇridˇelen´ y code a tajn´ y parametr secret. V pˇr´ıpadˇe, ˇze vˇse souhlas´ı, je vygenerov´an doˇcasn´ y autentizaˇcn´ı token (viz 2.2.1), kter´ ym se aplikace bude nad´ale prokazovat pˇri dalˇs´ıch poˇzadavc´ıch smˇerem k poskytovateli autentizace. Tento parametr je posl´an zpˇet do aplikace. 6. Nyn´ı aplikace vytvoˇr´ı instanci pomocn´e tˇr´ıdy restFB (viz 8.1.4), kter´a se identifikuje poskytovateli pˇridˇelen´ ym tokenem a zaˇza´d´a si o data. Na stranˇe Facebooku je vygenerov´an JSON objekt (viz 2.2.1), obsahuj´ıc´ı poˇzadovan´e informace3 , kter´ y je zasl´an zpˇet jako odpovˇed’ aplikaci. 7. Nyn´ı mohou nastat tˇri situace: • Uˇzivatel m´a jiˇz propojen´ y sv˚ uj u ´ˇcet v aplikaci se sv´ ym u ´ˇctem na Facebook.com (m´a u sv´eho u ´ˇctu v datab´azi vyplnˇen parametr FB_UID). V tomto pˇr´ıpadˇe doch´az´ı k automatick´emu pˇrihl´aˇsen´ı uˇzivatele do aplikace. • Uˇzivatel nem´a propojen´e u ´ˇcty a e-mail naˇcten´ y z Facebooku v aplikaci jeˇstˇe nen´ı registrov´an. Pot´e doch´az´ı k registraci uˇzivatele. Pˇrezd´ıvka je vytvoˇrena z pˇr´ıjmen´ı uˇzivatele a v pˇr´ıpadˇe, ˇze toto uˇzivatelsk´e jm´eno jiˇz v syst´emu existuje, je doplnˇeno o n´ahodn´ y ˇretˇezec 3
Z´ıskat lze pouze informace definovan´e v parametru scope u prvn´ıho poˇzadavku na server poskytovatele.
vytvoˇren´ y jako n´ahodn´e ˇc´ıslo v rozsahu <1;999>. V pˇr´ıpadˇe, ˇze je nalezeno unik´atn´ı pˇrihlaˇsovac´ı jm´eno, doch´az´ı k registraci a pˇrihl´aˇsen´ı uˇzivatele do syst´emu. • Uˇzivatel nem´a propojen´e u ´ˇcty a e-mail naˇcten´ y z Facebooku je jiˇz v aplikaci registrovan´ y. V tomto pˇr´ıpadˇe doch´az´ı k zastaven´ı registraˇcn´ıho (popˇr. pˇrihlaˇsovac´ıho) procesu a uˇzivatel je poˇza´d´an, aby se pˇrihl´asil pomoc´ı st´avaj´ıc´ıho u ´ˇctu v aplikaci a sv˚ uj u ´ˇcet propojil v administraci. Tento krok je nezbytn´ y, jelikoˇz v aplikaci nen´ı e-mail veden´ y jako unik´atn´ı parametr a n´asledn´e propojen´ı u ´ˇct˚ u by bylo nejednoznaˇcn´e.
8.1.4
Pouˇ zit´ e knihovny
Facebook umoˇzn ˇuje sd´ılen´ı sv´ ych dat pomoc´ı jednotn´eho rozhran´ı Facebook Graph Api. Pro komunikaci s t´ımto rozhran´ım byla pouˇzita knihovna RestFB, ˇs´ıˇrena pod licenc´ı MIT License. Po z´ısk´an´ı autentizaˇcn´ıho tokenu (viz 2.2.1) pomoc´ı ovˇeˇrovac´ıho mechanismu zm´ınˇen´eho v 8.1.3 je vytvoˇrena instance t´eto tˇr´ıdy spoleˇcnˇe s instanc´ı tˇr´ıdy User knihovny RestFB. FacebookClient facebookClient = new DefaultFacebookClient(MY_ACCESS_TOKEN); User userFb = facebookClient.fetchObject("me", User.class); Pˇr´ıstup k dat˚ um uˇzivatele pak prob´ıh´a pˇres objekt tˇr´ıdy User. Jednoduch´ y pˇr´ıklad naˇcten´ı z´akladn´ıch informac´ı o uˇzivateli a jejich pˇriˇrazen´ı objektu Person, kter´ y zajiˇst’uje pˇr´ıstup k uˇzivatel˚ um EEG/ERP port´alu. person = new Person(); person.setGivenname(userFb.getFirstName()); person.setSurname(userFb.getLastName()); person.setGender(userFb.getGender().toUpperCase().charAt(0)); person.setEmail(userFb.getEmail()); person.setDateOfBirth( new Timestamp(userFb.getBirthdayAsDate().getTime()));
46
Opravy bezpeˇcnostn´ıch chyb
8.1.5
Propojen´ı se Spring Security 2.0
Jelikoˇz je v aplikaci vyuˇzito zabezpeˇcovac´ıho frameworku Spring Security 2.0, kter´ y zajiˇst’uje pˇridˇelov´an´ı opr´avnˇen´ı uˇzivatel˚ um, bylo nutn´e i autentizaci pomoc´ı Facebook Connect s t´ımto frameworkem propojit.
Vlastn´ı autentizaˇ cn´ı token - Po u ´spˇeˇsn´e autentizaci je nutn´e uˇzivatele pˇrihl´asit do aplikace. Spring Security vyuˇz´ıv´a ke kontrole autentizace a t´ım z´aroveˇ n pˇr´ıstupu do aplikace autentizaˇcn´ı token. Po u ´spˇeˇsn´e autentizaci pomoc´ı Facebook Connect je jiˇz v aplikaci jasn´e, zda je uˇzivatel opr´avnˇen´ y pˇristupovat k chr´anˇen´ ym zdroj˚ um. Proto byl vytvoˇren vlastn´ı autentizaˇcn´ı token FacebookAuthenticationToken, kter´ y dˇed´ı vlastnosti tˇr´ıdy AbstractAuthenticationToken, jeˇz je souˇc´ast´ı Spring Security 2.0. Pˇrihl´aˇsen´ı uˇzivatele do syst´emu je uskuteˇcnˇeno proveden´ım n´asleduj´ıc´ıho k´odu: GrantedAuthority[] grantedAuthorities = new GrantedAuthorityImpl[1]; grantedAuthorities[0] = new GrantedAuthorityImpl(person.getAuthority()); Authentication a = new FacebookAuthenticationToken(grantedAuthorities, person); a.setAuthenticated(true); SecurityContextHolder.getContext().setAuthentication(a); Kde grantedAuthorities udrˇzuje seznam pˇridˇelen´ ych uˇzivatelsk´ ych rol´ı (napˇr. ROLE_ADMIN). SecurityContextHolder je bezpeˇcnostn´ı kontext Spring Frameworku, kter´emu je pˇred´an objekt urˇcuj´ıc´ı opr´avnˇen´ı pro sezen´ı uˇzivatele.
8.2
Opravy bezpeˇ cnostn´ıch chyb
V aplikaci byly opraveny vˇsechny nalezen´e chyby, kter´e bylo vhodn´e a technicky moˇzn´e realizovat. Hlavn´ımi opraven´ ymi bezpeˇcnostn´ımi nedostatky jsou :
47
Dalˇs´ı moˇzn´a vylepˇsen´ı bezpeˇcnosti
• Cross Site Scripting - Vˇsechny vstupy, kter´e umoˇzn ˇovaly vloˇzit JavaScript, byly oˇsetˇreny. Aplikace jiˇz nen´ı n´achyln´a na u ´tok prostˇrednictv´ım XSS. Nyn´ı tedy nen´ı moˇzn´e ani z´ıskat uˇzivatelsk´e session id a aplikace byla ˇca´steˇcnˇe zabezpeˇcena ohlednˇe Broken Authentication and Session Management. • Insecure Direct Object References - Vˇsechny zdroje, ke kter´ ym mohl m´ıt u ´toˇcn´ık pˇr´ıstup pˇres zmˇenu URL, byly zabezpeˇceny a uˇzivateli jsou k dispozici pouze chr´anˇen´e zdroje, ke kter´ ym je autorizov´an pˇristupovat. Ostatn´ı u ´pravy byly drobn´eho charakteru a implementovaly se v pr˚ ubˇehu v´ yvoje aplikace.
8.3
Dalˇ s´ı moˇ zn´ a vylepˇ sen´ı bezpeˇ cnosti
Vzhledem k technick´ ym moˇznostem aplikace nebylo moˇzn´e vˇsechna bezpeˇcnostn´ı rizika zcela odstranit. Proto by bylo ˇza´douc´ı z pohledu zabezpeˇcen´ı aplikace implementovat n´asleduj´ıc´ı rozˇs´ıˇren´ı, kter´a pomohou odstranit vˇsechny nalezen´e bezpeˇcnostn´ı nedostatky (viz 7).
8.3.1
SSL
Zaveden´ım SSL (resp. https) by byl eliminov´an Session Hijacking (viz 7.1.3), protoˇze odcizen´ı a nastaven´ı session id nestaˇc´ı u ´toˇcn´ıkovi k pˇrevzet´ı identity jin´eho uˇzivatele. V pˇr´ıpadˇe, ˇze by se pokusil u ´toˇcn´ık session id nastavit, bylo by zaˇsifrov´ano jeho unik´atn´ım kl´ıˇcem, a t´ım by vznikl jin´ y otisk, neˇz u uˇzivatele, kter´emu bylo session id odcizeno. Pˇri pouˇzit´ı protokolu https je vyuˇzito asymetrick´e ˇsifrov´an´ı, kde si klient i server pˇred zaˇc´atkem komunikace vygeneruj´ı priv´atn´ı a veˇrejn´ y kl´ıˇc, s jejichˇz vyuˇzit´ım je pak komunikace ˇsifrov´ana (V´ıce o SSL/TLS v [11]). Zaveden´ı SSL/TLS tak´e odstraˇ nuje bezpeˇcnostn´ı nedostatek Insufficient Transport Layer Protection (viz 5.1).
48
Dalˇs´ı moˇzn´a vylepˇsen´ı bezpeˇcnosti
8.3.2
´ Uprava uloˇ zen´ı hesla
Jelikoˇz je MD5 nedostateˇcn´ y algoritmus k zabezpeˇcen´ı hesel (viz [5]), bylo by vhodn´e jej nahradit nˇekter´ ym z bezpeˇcnˇejˇs´ıch algoritm˚ u, jako napˇr. SHA-256. Ten je v souˇcasn´e dobˇe povaˇzov´an za bezpeˇcn´ y, jelikoˇz nejsou zn´ama ˇz´adn´a dvˇe vstupn´ı slova, kter´a by d´avala po pr˚ uchodu algoritmem stejn´ y otisk. D´ale pro tento algoritmus nejsou prozat´ım rozˇs´ıˇren´e slovn´ıkov´e datab´aze, kter´e by obsahovaly seznam otisk˚ u pouˇz´ıvan´ ych hesel. Dalˇs´ım ˇreˇsen´ım ochrany s vyuˇzit´ım st´avaj´ıc´ıho MD5 algoritmu je moˇznost vyuˇz´ıt tzv. s˚ ul pˇri ukl´ad´an´ı a kontrole uˇzivatelsk´ ych hesel. Princip je pak takov´ y, ˇze v aplikaci je uloˇzen ˇretˇezec, kter´ y bude s´am o sobˇe povaˇzov´an za zabezpeˇcen´ y (dostateˇcn´a d´elka, speci´aln´ı znaky apod.). Vˇsechny ˇretˇezce, kter´e budou pozdˇeji uloˇzeny nebo porovn´any pomoc´ı algoritmu MD5, budou spojeny s t´ımto ˇretˇezcem a pot´e teprve bude pouˇzito MD5. Toto ˇreˇsen´ı je dostateˇcn´e a nebylo implementov´ano z d˚ uvodu jiˇz st´avaj´ıc´ıch hesel v datab´azi, kter´a se nepovedlo vˇsechna rozˇsifrovat do jejich p˚ uvodn´ı podoby, a proto nebylo moˇzn´e ani jejich n´asledn´e zaˇsifrov´an´ı s vyuˇzit´ım ”soli”.
8.3.3
Inovace technologi´ı st´ avaj´ıc´ıho ˇ reˇ sen´ı
Jedn´ım ze zlepˇsen´ı bezpeˇcnosti aplikace by jistˇe byla i inovace st´avaj´ıc´ıch technologi´ı. 1. Spring Framework 3.0 - Nov´a verze v´ yraznˇe usnadˇ nuje z´apis zdrojov´eho k´odu aplikace a zvyˇsuje jej´ı pˇrehlednost. Velk´e mnoˇzstv´ı souˇcasn´ ych modul˚ u vznik´a pouze s podporou Spring 3.0 a v´ yˇse. V pˇr´ıpadˇe naˇs´ı aplikace jsou zaj´ımav´e zejm´ena moduly Spring Security 3.0 a Spring Social. 2. Spring Security 3.0 - Nab´ız´ı zejm´ena rozˇs´ıˇren´e nastaven´ı spr´avce autentizace Authentication Manager, kter´ y nyn´ı umoˇzn ˇuje jednoduch´e pˇrid´av´an´ı dalˇs´ıch autentizaˇcn´ıch mechanism˚ u jako je napˇr. OpenID, Facebook Connect, Twitter Login apod. Konfigurace Spring Security je ve verzi 3.0 tak´e jednoduˇsˇs´ı a umoˇzn ˇuje ˇsifrov´an´ı komunikace a efektivnˇejˇs´ı spr´avu sessions. 3. Spring Social - Ofici´aln´ı modul pro Spring Framework by mohl nahradit a v´ yraznˇe zjednoduˇsit autentizaˇcn´ı mechanismus popsan´ y v 8.1.3. 49
Dalˇs´ı moˇzn´a vylepˇsen´ı bezpeˇcnosti
Spring Social tak´e nab´ız´ı vlastn´ı authentication provider v pˇr´ıpadˇe vyuˇzit´ı Spring Security 3.0. 4. Java Servlets 3.0 - Servlety 3.0 umoˇzn ˇuj´ı konfigurovat vyuˇzit´ı HttpOnly Cookies pˇr´ımo z aplikace. Nen´ı tedy nutn´e zasahovat do konfigurace serveru.
8.3.4
Ochrana proti CSRF
Jedinou v souˇcasnosti zn´amou technikou, kterou lze zamezit CSRF, je kombinace pˇrevodu GET parametr˚ u na POST, kontrola str´anky, ze kter´e uˇzivatel pˇriˇsel (referer) a vyuˇzit´ı unik´atn´ıho tokenu. • Pˇ revod GET parametr˚ u na POST - Veˇsker´e vol´an´ı akc´ı pˇrev´est z metody GET na POST. Toto opatˇren´ı u ´toˇcn´ıkovi nezabr´an´ı v u ´toku, jelikoˇz m˚ uˇze snadno pomoc´ı javascriptu automaticky odeslat formul´aˇr, kter´ y provede stejnou akci, jako by provedl, kdyby byl pˇres metodu GET. Tato metoda tedy znepˇr´ıjemn´ı u ´toˇcn´ıkovi situaci a v kombinaci s n´ıˇze uveden´ ym pouˇzit´ım unik´atn´ıho tokenu zcela zabr´an´ı CSRF. • Kontrola refereru - Kontrola str´anky, ze kter´e poˇzadavek pˇriˇsel, tak´e pouze znepˇr´ıjemn´ı u ´toˇcn´ıkovi situaci. V dneˇsn´ı dobˇe jiˇz umoˇzn ˇuj´ı programovac´ı a skriptovac´ı jazyky nastavit i tento parametr (viz [8]). • Unik´ atn´ı token - Toto implementaˇcnˇe sloˇzit´e ˇreˇsen´ı je u ´ˇcinn´a ochrana pˇred CSRF. Mechanismus spoˇc´ıv´a v generov´an´ı n´ahodn´eho tokenu, kter´ y se generuje pˇred proveden´ım operace. Pˇri jej´ım proveden´ı se tento token kontroluje a operace je u ´spˇeˇsnˇe dokonˇcena pouze v pˇr´ıpadˇe, ˇze tyto tokeny jsou shodn´e. T´ım doch´az´ı k tomu, ˇze vstupn´ı formul´aˇr je vˇzdy unik´atn´ı a u ´toˇcn´ıkovi to znemoˇzn´ı jeho replikaci. Probl´em pak tedy nast´av´a v pˇr´ıpadˇe, ˇze uˇzivatel chce m´ıt aplikaci otevˇrenou ve v´ıce oknech. V tomto pˇr´ıpadˇe doch´az´ı k vz´ajemn´emu ruˇsen´ı platnosti unik´atn´ıch token˚ u (v´ıce v [10]). V pˇr´ıpadˇe vyuˇzit´ı tˇechto tˇr´ı obrann´ ych mechanism˚ u by aplikace mˇela b´ yt proti CSRF dostateˇcnˇe zabezpeˇcena. Bohuˇzel kaˇzd´e z tˇechto ˇreˇsen´ı sebou pˇrin´aˇs´ı nˇejak´e probl´emy a je nutn´e jejich nasazen´ı d˚ uslednˇe zv´aˇzit.
50
9 Z´avˇer Aplikace EEG/ERP port´alu byla analyzov´ana nejen z hlediska bezpeˇcnosti, ale byly prozkoum´any i pr´avn´ı aspekty uchov´av´an´ı neuroinformatick´ ych dat ˇ e republiky. s ohledem na legislativu Cesk´ Po anal´ yze dat, kter´a aplikace zpracov´av´a, a dokumentu, kter´e mˇeˇren´a osoba podepisuje, bylo zjiˇstˇeno, ˇze veˇsker´e poˇzadovan´e pr´avn´ı n´aleˇzitosti dan´e z´akonem ˇc. 101/2000 Sb. jsou splnˇeny. Aplikace je tedy opr´avnˇena spravovat neuroinformatick´a data v rozsahu dan´em podepisovan´ ymi dokumenty. V pˇr´ıpadˇe anal´ yzy souˇcasn´eho ˇreˇsen´ı autentizaˇcn´ıch a autorizaˇcn´ıch mechanism˚ u bylo zjiˇstˇeno nˇekolik nedostatk˚ u, kter´e byly vz´apˇet´ı opraveny, pokud to bylo technicky moˇzn´e. St´avaj´ıc´ı moˇznosti autentizace byly rozˇs´ıˇreny o moˇznost pˇrihl´aˇsen´ı pomoc´ı extern´ıho autentizaˇcn´ıho poskytovatele, kter´ ym byl po d˚ ukladn´em zv´aˇzen´ı zvolen Facebook.com. Toto rozˇs´ıˇren´ı velmi usnadnilo proces registrace a pˇrihlaˇsov´an´ı do aplikace, kter´e je nyn´ı moˇzn´e bez ruˇcn´ıho vyplˇ nov´an´ı osobn´ıch nebo pˇrihlaˇsovac´ıch u ´daj˚ u. Nˇekter´a rozˇs´ıˇren´ı souˇcasn´eho ˇreˇsen´ı autentizace a autorizace v aplikaci nebylo moˇzn´e z technick´ ych d˚ uvod˚ u realizovat a n´avrh jejich zlepˇsen´ı je uveden v kapitole 8. Nejvˇetˇs´ım probl´emem pˇri ˇreˇsen´ı zad´an´ı byla dle m´eho n´azoru omezen´ı dan´a st´avaj´ıc´ımi technologiemi pouˇzit´ ymi v aplikaci. V souˇcasn´e dobˇe jiˇz existuj´ı jejich novˇejˇs´ı verze, kter´e by umoˇznily implementovat efektivnˇejˇs´ı ochranu proti nalezen´ ym bezpeˇcnostn´ım nedostatk˚ um popsan´ ych v 7. Jedinou v´ yj´ımkou je ochrana proti CSRF, proti kter´e v souˇcasn´e dobˇe neexistuje efektivn´ı ˇreˇsen´ı, kter´e by neomezovalo nejen v´ yvoj´aˇre pˇri tvorbˇe aplikace, ale zejm´ena uˇzivatele, kteˇr´ı aplikaci pouˇz´ıvaj´ı (viz 8.3.4).
51
Pˇ rehled zkratek AJAX - Asynchronous JavaScript and XML API - Application Programming Interface DAO - Data Access Object DI - Dependency Injection HQL - Hibernate Query Language HTML - Hypertext Markup Language HTTP - Hypertext Transfer Protocol IoC - Inversion of Control ISO - International Organization for Standardization J2EE - Java to Enterprise Edition JVM - Java Virtual Machine JSON - JavaScript Object Notation JSP - Java Server Pages JSTL - JavaServer Pages Standard Tag Library MD-5 - Message Digest Algorithm OS - Operaˇcn´ı syst´em ORM - Objektovˇe-relaˇcn´ı mapov´an´ı OWASP - The Open Web Application Security Project PIN - Personal Identification Number RP - Relying Party SQL - Structured Query Language SaaS - Software as Service SSL - Secure Sockets Layer UTF - UCS Transformation Format USID - User Supplied Identifier XML - Extensible Markup Language
52
Literatura [1] BEN ALEX, L. T. Spring Security 2.0 - Reference Documentation. Spring Source, 2008. Dostupn´e z: . [2] CRAIG WALLS, R. B. Spring in Action (Second Edition). USA : Manning Publications Co., 2008. ISBN 1932394354. [3] FOUNDATION, O. OpenID Authentication 2.0. OpenID Foundation, 2007. Dostupn´e z: . [4] JEREMIAH GROSSMAN, P. D. P. A. R. S. F. R. H. XSS Attacks cross site scripting, exploits and defense. Brno : Amorette Pedersen, 2007. ISBN 1-59749-154-3. [5] KLIMA, V. Haˇsovac´ı funkce MD5 a dalˇs´ıch prolomeny. ROOT.cz, 2004. Dostupn´e z: . [6] OWASP.ORG. OWASP Top 10 2010. Owasp Foundation, 2011. Dostupn´e z: . [7] PROJECT, T. O. W. A. S. A Guide to Building Secure Web Applications. OWASP, 2010. Dostupn´e z: . [8] SHEMA, M. Seven Deadliest Web Application Attacks. Burlington, USA : Syngress, 2010. ISBN 978-1597495431. [9] SHIFETT, C. Essential PHP Security. Gravenstein Highway, Sebastopol, USA : O´REILLY, 2006. ISBN 978-0596006563.
53
[10] SHIFLETT, C. Foiling Cross-Site Attacks. shiflett.org, 2003. Dostupn´e z: . [11] THOMAS, S. SSL and TLS Essentials. Canada : John Wiley & Sons, Inc., 2000. ISBN 0-47-38354-6. [12] UOOU.CZ. Z´akon ˇc. 101/2000 Sb., o ochranˇe osobn´ıch u ´daj˚ u (´ uˇcinn´e ´ znˇen´ı). Uˇrad pro ochranu osobn´ıch u ´daj˚ u, 2000. Dostupn´e z: .
Pˇ r´ılohy
55
A Podm´ınky u´ˇcasti v projektu s n´ azvem Mˇ eˇ ren´ı mozkov´ e aktivity“ ” A.1
Popis projektu
ˇ REN ˇ ´I MOZKOVE ´ AKTIVITY“ (d´ale jen projekt“) C´ılem projektu ME ” ” je zjiˇstˇen´ı zmˇen mozkov´e aktivity ˇclovˇeka zejm´ena v situac´ıch, kter´e vyˇzaduj´ı soustˇredˇen´ı (ˇreˇsen´ı logick´ ych probl´em˚ u, poˇc´ıt´an´ı, hran´ı her), kreativn´ı ˇcinnost (sestavov´an´ı stavebnic, kreslen´ı obr´azk˚ u), ˇcinnost vyˇzaduj´ıc´ı vyuˇzit´ı pamˇeti (zapamatov´an´ı si urˇcit´ ych vˇec´ı a n´asledn´e odpovˇedi na ot´azky) nebo zjiˇstˇen´ı zmˇen mozkov´e aktivity v pˇr´ıpadech, kdy je ˇclovˇek bl´ızko sp´anku (polosp´anku). Dalˇs´ım c´ılem projektu je srovn´an´ı vlivu nˇekter´ ych faktor˚ u, jako je napˇr. alkohol, u ´nava nebo stres na v´ ykon v´ yˇse uveden´ ych ˇcinnost´ı. Z´aroveˇ n s EEG mˇeˇren´ım je moˇzn´e prov´adˇet i mˇeˇren´ı EKG a vyhodnocovat tak EEG a EKG v z´avislosti na uveden´ ych faktorech. Mˇeˇren´ı EKG je dobrovoln´e a m˚ uˇze b´ yt mˇeˇrenou osobou odm´ıtnuto. V pˇr´ıpadˇe zam´ıtnut´ı se bude prov´adˇet pouze mˇeˇren´ı EEG aktivity. Pˇredmˇetn´a mˇeˇren´ı budou prov´adˇena na osobˇe, kter´a po splnˇen´ı tˇechto podm´ınek u ´ˇcasti v projektu podstoup´ı samotn´e mˇeˇren´ı mozkov´e aktivity. Veˇsker´e pˇr´ıstroje, vybaven´ı, vˇcetnˇe pˇr´ısluˇsenstv´ı a materi´al jsou bˇeˇznˇe pouˇz´ıv´any ve zdravotnictv´ı.
A.2
Pr˚ ubˇ eh mˇ eˇ ren´ı
Mˇeˇren´ı mozkov´e aktivity probˇehne podle n´asleduj´ıc´ıho postupu a. osoba je detailnˇe sezn´amena s pr˚ ubˇehem mˇeˇren´ı a je j´ı vysvˇetleno to, co se od n´ı oˇcek´av´a b. osobˇe se nasad´ı EEG ˇcepice a namaˇze se vodiv´ ym gelem
56
c. z´aroveˇ n s mˇeˇren´ım EEG je moˇzn´e mˇeˇrit i EKG. Pokud osoba s mˇeˇren´ım EKG souhlas´ı, provede se nalepen´ı EKG elektrod na hrudn´ık. d. zkontroluje se vodivost elektrod e. probˇehne pˇripojen´ı se na EEG /EKG pˇr´ıstroj (pˇr´ıstroj je nap´ajen bateri´ı o napˇet´ı 3 V) f. spust´ı se program na poˇc´ıtaˇci a osoba je vyzv´ana, aby odpovˇedˇela na ot´azky t´ ykaj´ıc´ı se zdravotn´ıho stavu, psychick´eho stavu a n´avyk˚ u. Rozsah ot´azek je uveden v pˇr´ıloze, kter´a je ned´ılnou souˇc´ast´ı tohoto pouˇcen´ı g. pot´e se spust´ı program, kter´ y zobrazuje pokyny, kter´e m´a osoba vykon´avat (otev´ır´an´ı/zav´ır´an´ı oˇc´ı, hlubok´e d´ ych´an´ı) a dalˇs´ı pokyny souvisej´ıc´ı se zjiˇstˇen´ım mozkov´e aktivity (poˇcetn´ı pˇr´ıklady, ot´azky, hran´ı her, ˇreˇsen´ı u ´loh) h. z´ıskan´e u ´daje budou uloˇzeny do lok´aln´ı datab´aze nebo uloˇzeny na internetov´e str´anky; k uveden´ ym datab´az´ım budou m´ıt pˇr´ıstup pouze opr´avnˇen´e osoby pod´ılej´ıc´ı se na ˇreˇsen´ı projektu, pˇriˇcemˇz u ´daje budou v datab´az´ıch standardnˇe zabezpeˇceny heslem, krytov´an´ım a/nebo anonymizac´ı i. osoba je v pr˚ ubˇehu mˇeˇren´ı zaznamen´av´ana videokamerou, pˇriˇcemˇz z´aznam je spolu s namˇeˇren´ ymi u ´daji ukl´ad´an; se souhlasem je osoba t´eˇz vyfocena j. po skonˇcen´ı mˇeˇren´ı jsou osobˇe poskytnuty z´akladn´ı hygienick´e pom˚ ucky
A.3
Podm´ınky u ´ˇ casti v projektu
´ cast osoby v projektu je dobrovoln´a a. Uˇ b. Projektu se m˚ uˇze z´ uˇcastnit v´ yhradnˇe osoba, kter´a je starˇs´ı 18 let c. Osoba prohl´as´ı, je j´ı nen´ı zn´ama ˇza´dn´a skuteˇcnost, kter´a by mohla m´ıt vliv na zmˇenu jej´ıho zdravotn´ıho vztahu d. Osoba podep´ıˇse tyto podm´ınky u ´ˇcasti v projektu
A.4
Prohl´ aˇ sen´ı
Podpisem tˇechto podm´ınek u ´ˇcasti v projektu prohlaˇsuji, ˇze jsem se detailnˇe sezn´amil s tˇemito podm´ınkami u ´ˇcasti v projektu, a ˇze jim rozum´ım. Podpisem tˇechto podm´ınek u ´ˇcasti v projektu prohlaˇsuji, ˇze mi nejsou zn´amy ˇz´adn´e skuteˇcnosti, kter´e by moji u ´ˇcast v projektu znemoˇzn ˇovaly nebo omezovaly, zejm´ena si pak nejsem vˇedom ˇz´adn´ ych omezen´ı souvisej´ıc´ıch s m´ ym celkov´ ym zdravotn´ım nebo psychick´ ym stavem. Podpisem tˇechto podm´ınek u ´ˇcasti v projektu prohlaˇsuji, ˇze jsem si vˇedom skuteˇcnosti, ˇze u ´ˇcast v projektu u ´zce souvis´ı s m´ ym aktu´aln´ım zdravotn´ım a psychick´ ym stavem a jsem si vˇedom t´eˇz toho, ˇze uveden´ı nepravdiv´ ych, ne´ upln´ ych nebo nespr´avn´ ych informac´ı, t´ ykaj´ıc´ıch se zejm´ena m´eho zdravotn´ıho nebo psychick´eho stavu m˚ uˇze m´ıt na tento zdravotn´ı nebo psychick´ y stav vliv. Podpisem tˇechto podm´ınek u ´ˇcasti v projektu prohlaˇsuji, ˇze jsem pˇred zapoˇcet´ım mˇeˇren´ı nepoˇzil alkohol ani nejsem pod vlivem n´avykov´ ych nebo psychotropn´ıch l´atek, zejm´ena drog.
A.5
Souhlas se zpracov´ an´ım osobn´ıch u ´ daj˚ u
Podpisem tˇechto podm´ınek u ´ˇcasti v projektu udˇeluji ve smyslu z´akona ˇc. 101/2000 Sb., o ochranˇe osobn´ıch u ´daj˚ u a o zmˇenˇe nˇekter´ ych z´akon˚ u, ve znˇen´ı pozdˇejˇs´ıch pˇredpis˚ u Z´apadoˇcesk´e univerzitˇe v Plzni a Fakultn´ı nemocnici Plzeˇ n po pouˇcen´ı o sv´ ych pr´avech v´ yslovn´ y souhlas se zpracov´an´ım osobn´ıch a citliv´ ych u ´daj˚ u v rozsahu tˇechto podm´ınek u ´ˇcasti v projektu, vˇcetnˇe pˇr´ılohy, kter´a je ned´ılnou souˇc´ast´ı tohoto pouˇcen´ı, za u ´ˇcelem realizace a n´asledn´eho vyhodnocen´ı projektu. Tento souhlas udˇeluji na dobu realizace projektu a n´aslednˇe po dobu . . . 5. . . let po jeho skonˇcen´ı. Jsem si vˇedom(a) toho, ˇze poskytnut´ı osobn´ıch a citliv´ ych u ´daj˚ u je dobrovoln´e, a ˇze souhlas se zpracov´an´ım osobn´ıch nebo citliv´ ych u ´daj˚ u mohu kdykoli odvolat. V Plzni dne. . . . . . . . . . . . Souhlas´ım s mˇeˇren´ım EKG Nesouhlas´ım s mˇeˇren´ım EKG _____________________ podpis u ´ˇcastn´ıka v projektu
B EEG Metadata B.1
Informace o mˇ eˇ ren´ e osobˇ e
• X Jm´eno a pˇr´ıjmen´ı • X Datum narozen´ı • X Pohlav´ı • Pocity bˇehem mˇeˇren´ı (´ unava, ˇspatn´e soustˇredˇen´ı,. . . ) • Porucha zraku • Porucha sluchu • X Kontakt • X Prav´ak/Lev´ak
B.2
Informace o mˇ eˇ r´ıc´ı osobˇ e
• X Jm´eno a pˇr´ıjmen´ı • Zkuˇsenost • X Kontakt (e-mail, telefon . . . )
B.3
Podm´ınky mˇ eˇ ren´ı
• X Datum mˇeˇren´ı ˇ mˇeˇren´ı • X Cas • D´elka mˇeˇren´ı (vˇcetnˇe pˇr´ıpravy) • X Pouˇzit´e pˇr´ıstroje • X Pouˇzit´a ˇcepice 59
´ cel mˇeˇren´ı (reakce pˇri pln´e koncentraci, reakce pˇri u • Uˇ ´navˇe, alkohol, drogy . . . ) • Zapojen´ı elektrod • Teplota v m´ıstnosti • Ruˇsen´ı (zmˇena osvˇetlen´ı, hluk . . . ) • X Vzorkovac´ı frekvence • Poˇcas´ı • Jin´e d˚ uleˇzit´e poznatky
B.4
Informace o sc´ en´ aˇ ri
• X N´azev • D´elka sc´en´aˇre • X Autor • X Kontakt (e-mail, telefon . . . ) • Popis • Vlastn´ı sc´en´aˇr • X Verze
C Obsah DVD K dokumentu je pˇriloˇzeno DVD jehoˇz adres´aˇrov´a struktura je n´asleduj´ıc´ı: 1. bin - Obsahuje spustiteln´ y soubor eegbase.war, kter´ y je moˇzn´e spustit ve vˇetˇsinˇe webov´ ych kontejner˚ u jako napˇr. Jetty, Apache Tomcat apod. 2. doc - Obsahuje tento dokument ve form´atu PDF. 3. src - Obsahuje zdrojov´e k´ody aplikace. Spustiteln´ y soubor a zdrojov´e k´ody odpov´ıdaj´ı revizi aplikace ˇc. 913 (SVN na http://eeg-database.origo.ethz.ch/ ) a release verzi ˇc. 255 (na build serveru Hudson na testovac´ım veˇrejn´em serveru).
