V t´eto kapitole se pokus´ım nast´ınit 10 nejzn´amˇejˇs´ıch bezpeˇcnostn´ıch rizik pro webov´e aplikace. U kaˇzd´eho rizika rovnˇeˇz uv´ad´ım druhy ochran v aplikaci SQL Tester. Vych´azel jsem ze seznamu organizace OWASP [14].
7.6.1 SQL Injection
SQL Injection je technika, kdy ´utoˇcn´ık pomoc´ı formul´aˇre modifikuje vykon´avan´y SQL dotaz a pˇrid´a do nˇej vlastn´ı SQL pˇr´ıkaz. Napˇr´ıklad bychom na serveru mˇeli n´asleduj´ıc´ı SQL dotaz.
sql = "SELECT * FROM Users WHERE UserId = " + txtUserId;
7 ZABEZPE ˇCEN´I
Tento pˇr´ıkaz by mˇel vr´atit maxim´alnˇe jednoho uˇzivatele. Pˇredpokl´ad´ame, ˇze UserId je unik´atn´ı identifik´ator uˇzivatele. Parametr txtUserId pˇrevezmeme od uˇzivatele pomoc´ı for-mul´aˇrov´eho pole. Uˇzivatel zad´a napˇr´ıklad 125 or 1=1. Nyn´ı se pod´ıv´ame na pˇr´ıkaz, kter´y se vykon´a.
SELECT * FROM Users WHERE UserId = 125 or 1=1;
Takov´y dotaz uˇz z´ısk´a vˇsechny uˇzivatele z datab´aze. Proti SQL Injection se d´a br´anit pa-rametrizovan´ymi dotazy. Dotaz se tedy nespojuje pomoc´ı ˇretˇezc˚u, ale vloˇz´ı se do nˇej para-metry, kter´e budou parsov´any jako hodnoty. Parametrizovan´e dotazy vyuˇz´ıv´am i v aplikaci SQL Tester. N´ıˇze je uk´azka k´odu, kde je dotazu pˇred´an parametr role.
@Query("SELECT u FROM User u WHERE u.role.name = :role") public List<User> findByRoleName(@Param("role") String role);
7.6.2 Odcizen´ı hesel a spr´ava sessions
Utoˇ´ cn´ık se pokouˇs´ı napˇr´ıklad deˇsifrovat z´ıskan´e heslo nebo jej vid´ı v ˇciteln´e podobˇe. Proto je v aplikaci SQL Tester heslo pro administr´atorsk´y ´uˇcet vytvoˇreno funkc´ı bcrypt. Heslo je tedy zaˇsifrovan´e a je k nˇemu pˇrid´ana tzv. s˚ul. To je ˇretˇezec, kter´y se pˇripoj´ı k heslu pˇred samotn´ym ˇsifrov´an´ım. Je tedy velice obt´ıˇzn´e p˚uvodn´ı heslo deˇsifrovat. Ostatn´ı uˇzivatel´e se autentizuj´ı pomoc´ı Shibbolethu, takˇze zde moje aplikace nehraje roli. Komunikace s Shi-bbolethem prob´ıh´a pˇres HTTPS. Podvrˇzen´ı autorizace ˇci autentizace uˇzivatele lze prov´est z´ısk´an´ım session ID. Nˇekter´e aplikace jej zas´ılaj´ı v URL. Na serveru jsem tuto moˇznost za-mezil a lze session ID pˇred´avat pouze pomoc´ı cookies. Nav´ıc pˇri nov´em pˇrihl´aˇsen´ı uˇzivatele se vˇsechny sessions vytvoˇr´ı znovu a star´e se zneplatn´ı. Toho jsem dos´ahl prostˇrednictv´ım konfigurace Spring Security. Posledn´ı ochrana proti t´eto zranitelnosti je platnost sessions po dobu 30 minut. Cookies je tak´e moˇzn´e zas´ılat pouze prostˇrednictv´ım HTTPS. Nelze je tedy odcizit napˇr´ıklad javascriptem.
7.6.3 XSS
XSS (Cross-site scripting) je ´utok, pˇri nˇemˇz na str´ance zobraz´ıme neˇz´adouc´ı data, kter´a n´am dˇr´ıve zadal uˇzivatel. Mezi neˇz´adouc´ı data ˇrad´ıme napˇr´ıklad HTML nebo v horˇs´ım pˇr´ıpadˇe javascript, kter´y napˇr´ıklad zcela zmˇen´ı vzhled a funkcionalitu str´anky. V aplikaci
7 ZABEZPE ˇCEN´I
zajiˇst’uje ochranu proti XSS escapov´an´ı speci´aln´ıch znak˚u pˇri v´ypisu.
<h:outputText value="#{taskBean.question}" />
Jedinou v´yjimku tvoˇr´ı rozhran´ı, kde uˇcitel zad´av´a specifikaci datab´aze. Tady m´a pˇrichystan´y HTML editor, v nˇemˇz nen´ı moˇzn´e mˇenit zdrojov´y k´od pˇr´ımo. Pˇr´ıpadn´e speci´aln´ı znaky tedy rovnˇeˇz budou escapov´any. Uk´azka pro v´ypis z HTML editoru.
<h:outputText value="#{solutionBean.database.specification}" escape="false" />
7.6.4 Nezabezpeˇcen´e pˇr´ım´e odkazy na objekty
Uˇzivatel se m˚uˇze napˇr´ıklad pomoc´ı URI dostat k soubor˚um, ke kter´ym by nemˇel m´ıt nikdo pˇr´ıstup. M˚uˇze to b´yt napˇr´ıklad konfigurace datab´aze. J´a m´am vˇsechny neveˇrejn´e zdroje ve sloˇzce s n´azvem WEB-INF, kter´a je pro uˇzivatele nepˇr´ıstupn´a. Tak´e zde m´am facelety, kter´e se vkl´adaj´ı do ˇsablony. To je moje osobn´ı vylepˇsen´ı n´avrhu oproti tˇem, kter´e jsem mˇel na internetu moˇznost vidˇet. Nˇekter´e URL jsou rovnˇeˇz zabezpeˇceny na z´akladˇe uˇzivatelsk´ych rol´ı. Dalˇs´ı moˇznost´ı pro ´utoˇcn´ıka je pozmˇenit parametr a z´ıskat data, kter´a mu nepatˇr´ı. J´a naˇc´ıt´am do pamˇeti pouze objekty, ke kter´ym uˇzivatel pˇr´ıstup m´a a jin´e modifikovat nelze.
Pokud by se objekt nenach´azel v pamˇeti, pak neprojde validace vstupu.
7.6.5 Nebezpeˇcn´a konfigurace
Utoˇ´ cn´ık m˚uˇze vyuˇz´ıt aktu´aln´ı pˇrednastaven´e konfigurace, kter´a b´yv´a ˇcasto nebezpeˇcn´a.
Proto jsem konfiguraci pozmˇenil. Vytvoˇril jsem tak´e vlastn´ı chybov´e str´anky a aplikace je v reˇzimu ostr´eho nasazen´ı a nevypisuje tedy pˇr´ıpadn´e chyby. Na serveru ani neexistuj´ı ˇ
z´adn´e pˇrednastaven´e ´uˇcty.
7.6.6 Zveˇrejnˇen´ı citliv´ych dat
Utoˇ´ cn´ık m˚uˇze vyuˇz´ıt pˇren´aˇsen´ych dat v ˇciteln´e textov´e podobˇe, slab´ych zastaral´ych ˇsifer apod. Na serveru jsem nastavil komunikaci v´yhradnˇe prostˇrednictv´ım protokolu HTTPS.
Heslo administr´atora je uloˇzeno pomoc´ı funkce bcrypt a komunikace s Shibbolethem prob´ıh´a rovnˇeˇz prostˇrednictv´ım HTTPS. Na nˇekter´ych formul´aˇr´ıch, kde je to vhodn´e, rovnˇeˇz zaka-zuji automatick´e doplˇnov´an´ı na z´akladˇe pˇredchoz´ıch relac´ı.
7 ZABEZPE ˇCEN´I
7.6.7 Chyby v ˇr´ızen´ı ´urovn´ı pˇr´ıstup˚u
Pˇr´ıstup k URL je ˇr´ızen na z´akladˇe uˇzivatelsk´ych rol´ı a nepovolen´y uˇzivatel si tedy nem˚uˇze zobrazit obsah, kter´y mu nen´ı urˇcen´y. Nicm´enˇe nic by mu nebr´anilo zavolat funkci na serveru. Proto kaˇzd´a funkce v Controlleru je opatˇrena anotac´ı @Secured. Ta zajist´ı spuˇstˇen´ı metody pouze uˇzivatelem se spr´avn´ym opr´avnˇen´ım. Jelikoˇz anotace funguje pro Spring Web MVC, musel jsem jej´ı chov´an´ı poupravit, aby fungovala i v kombinaci s JSF. Vyuˇzil jsem k tomu AOP.
7.6.8 CSRF
CSRF (Cross-Site Request Forgery) je metoda, pˇri n´ıˇz se snaˇz´ı ´utoˇcn´ık odeslat formul´aˇr z ciz´ıho zdroje a vyd´avat se pˇritom za autorizovan´eho uˇzivatele. Formul´aˇr z ciz´ıho zdroje v aplikaci SQL Tester odeslat zabraˇnuji. V aplikaci vyuˇz´ıv´am takˇrka v´yhradnˇe metody POST nikoli GET. Metody POST znesnadˇnuj´ı proveden´ı CSRF, ale rozhodnˇe mu ne-zabr´an´ı. K tomu slouˇz´ı token. Jedn´a se o n´ahodnˇe vygenerovanou hodnotu, kter´a se vy-generuje pˇri zobrazen´ı formul´aˇre na origin´aln´ı str´ance. Bez tohoto tokenu nelze formul´aˇr odeslat. JSF a Spring Security v aplikaci implementuj´ı CSRF ochranu pomoc´ı tokenu au-tomaticky.
7.6.9 Pouˇzit´ı zn´am´ych zraniteln´ych komponent
Pro svoji aplikaci jsem se snaˇzil vyb´ırat zn´am´e open-source projekty, kter´e maj´ı dobr´y v´yvoj a dokumentaci. Z´aroveˇn jsem vyuˇzil nejnovˇejˇs´ıch verz´ı a komponenty jsou tak aktu´aln´ı.
7.6.10 Neoˇsetˇren´e pˇresmˇerov´an´ı a pˇred´av´an´ı
Jelikoˇz ˇz´adn´e pˇresmˇerov´an´ı nevyuˇz´ıv´am, tak je aplikace proti tomuto druhu zranitelnosti chr´anˇena. Jedin´e pˇresmˇerov´an´ı m˚uˇze b´yt na chybov´e str´anky.
7.6.11 Clickjacking
Clickjacking mezi top 10 rizik podle OWASP nepatˇr´ı, ale i tak jej zm´ın´ım. Jedn´a se o tech-niku, kdy se po kliknut´ı na nˇejak´y prvek na str´ance, napˇr´ıklad tlaˇc´ıtko, provede jin´a akce neˇz oˇcek´av´ame. Tlaˇc´ıtko m˚uˇze b´yt tˇreba pˇrekryto neviditeln´ym odkazem. Spring Security zajiˇst’uje automatickou ochranu proti tomuto ´utoku.
7 ZABEZPE ˇCEN´I