Každá aplikace a data, která zpřístupňuje, jsou v reálném světě vystaveny
bezpečnostním rizikům. Tato rizika jsou tím závažnější, čím důležitější
je bezproblémový chod aplikace a souvisejících dat. Aplikace se ale může
stát i vstupní branou pro ovládnutí celého počítače, což může mít ještě 
daleko závažnější následky.


\section{Základní druhy ohrožení}

Ohrožení bezpečnosti se týká několika oblastí.

\begin{itemize}

\item Porušení důvěrnosti dat.

\item Ztráta dat.

\item Neoprávněná modifikace dat.

\item Získání přístupových práv k počítači.

\item Přerušení dostupnosti služby.

\end{itemize}

V praxi se lze setkat s různými pokročilými požadavky z oblasti bezpečnosti,
jako je vedení záznamů o provedených změnách a jejich původcích. Tuto
problematiku však v mé aplikaci, po konzultaci se zadavatelem, neřeším a nebudu
se jí zabývat ani v této kapitole.

{\odstavec
Zachování důvěrnosti je založeno na předpokladu, že informace mohou číst pouze
osoby oprávněné. Tento předpoklad je splněn tenkrát, když:
}

\begin{itemize}

\item
Systém dokáže rozlišovat mezi osobami oprávněnými k přístupu a osobami neoprávněnými.

\item
Systém zamezí přístupu osobám neoprávněným.
        
\end{itemize}

Důvěrnost dat v souborovém systému je dána rozumně nastavenými přístupovými právy,
v případě webové aplikace je třeba s tímto požadavkem počítat v návrhu aplikace.
O přijatých opatřeních v databázi benchmarků se zmíním v dalším textu.

{\odstavec
Ztráta dat může být způsobena nejenom zásahem útočníka, ale i omylem obsluhy,
chybou hardware a jinými příčinami. Proto je třeba nejenom bránit útočníkům
zvenčí přistupovat k datům, ale je třeba zachovat pravidlo co nejmenších práv
pro oprávněné osoby a data pravidelně zálohovat. Zálohování databáze benchmarků
spočívá v zálohování uložených souborů a zálohování samotné databáze - například
formou tzv. SQL dumpu.

Neoprávněné modifikaci lze opět zabránit kontrolou přístupu a v případě, že
situace nastane, obnovením dat ze zálohy.

Získání přístupových práv k počítači je možné obvykle díky chybám v software
třetích stran nebo špatnému návrhu programu. O obou možných problémech se
zmíním v dalším textu.

Přerušení dostupnosti služby (DoS) je komplexní problém, který lze dobrým návrhem
pouze omezit, ale zabránit mu zcela nelze. Obranou před přerušením dostupnosti
služby, pokud vyloučíme záměrný útok, je efektivně navržená aplikace.
}

\section{Bezpečnostní rizika řádkových skriptů}

Řádkové skripty psané v jazyce Python jsou z bezpečnostního
hlediska poměrně malou hrozbou. 

{ \odstavec
Parser benchmarků je spouštěn z lokálního počítače a obyčejně i
s právy, která odpovídají běžnému uživateli. Jazyk Python je odolný
proti chybám typu buffer overflow a neobsahuje žádná volání externích
programů, takže nebezpečí jeho zneužití při spuštění z příkazové řádky
je minimální.

Určitým problémem by mohlo být jeho spuštění ze serveru s cílem vyvolat DoS
útok, který by měl za cíl způsobit zpomalení serveru a zahlcení jeho paměti.

Skript pro přípravu archivu pro agregované stahování by teoreticky
mohl být dalším cílem útoku. Uvědomíme-li si ale, že soubory se do archivu přidávají
na základě SQL dotazu vytvořeného naším PHP skriptem, je riziko zneužití minimální.

}

\subsection{Kontrola přístupu}

Kontrola přístupu byla rozdělena na čtyři oblasti:

\begin{itemize}

\item Přístup k prohlížení dat benchmarků.

\item Přístup k modifikaci dat benchmarků.
    
\item Přístup k editaci uživatelských účtů.

\item Možnost změny vlastního hesla.
        
\end{itemize}

Prohlížet data benchmarků může podle nastavení aplikace buďto kdokoliv, kdo
má přístup na stránky webového rozhraní, nebo pouze osoba přihlášená. Zatímco
nutnost přihlašování snižuje pohodlí uživatele, zamezuje to, zvláště v případě
vystavení stránky na Internetu, riziku zvýšeného zatížení serveru. Po přihlášení
smí prohlížet data kterýkoliv uživatel s platným účtem.

{\odstavec
Modifikace dat je v databázi benchmarků povolena pouze pro přihlášené uživatele
s příslušným oprávněním.

Uživatelské účty lze modifikovat pouze s příslušným oprávněním. Z bezpečnostního
hlediska bych chtěl vyzvednout dva aspekty návrhu: Uživatel nesmí modifikovat
vlastní přístupová práva (to má význam zejména jako ochrana před naúmyslným zrušením
práv uživatele) a uživatel nevidí hesla jiných uživatelů. Editace hesel je řešena
jejich přepsáním, nikoliv editací.

Změna vlastního hesla může být u některých uživatelských účtů zakázáno. Význam
to může mít například při hromadném sdělení jednoho uživatelského hesla více osobám
(předpokládám přístup pro čtení), kde by zlomyslná nebo nechtěná změna hesla
jedním z nich ohrozila přístup ostatních. Při změně vlastního hesla je nutno zadat
původní heslo a pro snížení možnosti chyby zadat nové heslo dvakrát.
}

\subsection{Vyřešení autorizace uživatele}

Autorizace uživatele probíhá zadáním uživatelského jména a hesla. V průběhu
práce je identifikace uživatele sledována pomocí tzv. relace za pomocí
PHP kódu ve spolupráci s prohlížečem na straně klienta.  Relace se ukládá
pomocí cookie a reprezentuje ji jednoznačný, náhodně generovaný identifikátor.
Po zadání platného uživatelského jména a hesla je uživatelský účet zpárován s
existující relací daného uživatele. 

{\odstavec
Nebezpečím je možnost odcizení nebo uhodnutí identifikátoru relace. Uhodnutí,
předpokládáme-li rozumnou implementaci generátoru identifikátorů, nepřichází
příliš v úvahu.

Odcizení identifikátoru je podstatně reálnější hrozbou. Existují tři místa, kde
by bylo teoreticky možné cizí identifikátor získat: Počítač klienta, server a
přenosový kanál mezi klientem a serverem. Získání identifikátoru na klientském
počítači není nic, co bychom mohli ovlivnit, protože je plně v rukou správce
klientského počítače, aktuálního uživatele počítače a klientského programu, tj.
webového browseru. Odcizení na straně serveru je možné díky úspěšnému útoku na
server a zabezpečení serveru jako takového na tomto místě řešit nebudu. Ochranou
přenášených dat se zabývám dále v textu.
}

\subsection{Ochrana před nahráním příliš velkého souboru}

Nahrání příliš velkého souboru může mít za následek zahlcení serveru. Základní
ochranou je omezení velikosti nahrávaných souborů přímo na 

\subsection{Ochrana přenášených dat}

Přenášená data jsou ohrožena rizikem, že k nim získá přístup neoprávněná osoba.
Ochrany dat přenášených po síti se dá docílit šifrovaným spojením (SSL, TLS).
V návrhu databáze šifrování spojení neřeším, ale je možné zajistit šifrování
spojení vhodnou konfigurací webového serveru.

\subsection{Ochrana softwarového prostředí prostředky třetích stran}

Každý program může obsahovat bezpečnostní chybu. U kompilovaných programů, zejména
těch, které jsou psány v jazycích typu C, je riziko poměrně vysoké. Mezi nejznámější
problémy patří přetečení bufferu, které, i přesto, že příčiny i řešení jsou vcelku
obecně známé, se čas od často vyskytuje i ve známých a oblíbených programech. 

{\odstavec
Pro interpreter PHP existuje projekt zvaný \textit{Hardened-PHP Project}, zvaný
též Suhosin. Tento projekt obsahuje nízkoúrovňovou ochranu proti přetečení bufferu
a zranitelnosti formátovacích řetězců a ochranu, která řeší některé potenciální
problémy v návrhu samotné aplikace psané v PHP.

Pro ochranu hostitelského počítače před útokem pomocí webové (nebo jiné)
aplikace lze též využít některou z možností izolace aplikace. Mezi oblíbené možnosti
patří tzv. chroot prostředí - program běží v rámci samostatného podadresáře, který
simuluje celý souborový systém a operační systém mu znemožní překročit hranice
tohoto podadresáře. Další možností je využití některé z možností virtualizace -
mezi oblíbené možnosti patří například VMWare, Xen, User-mode Linux.

Pilotní instalace databáze benchmarků využívá jak projektu Suhosin, tak i virtuálního
serveru, který projekt sdílí s některými jinými projekty. Konkrétní rozhodnutí je
ale v tomto případě vždy v rukou správce serveru či aplikace.
}

% vim:enc=iso8859-2:fenc=iso8859-2:syntax=tex:
