V dnešní době je obvyklé nahrazovat běžné aplikace, jejichž vývoj je relativně nákladný, odlehčenou variantou – aplikacemi s webovým rozhraním. Platforma pro psaní aplikací je to rozhodně lákavá. Jsou oblasti, ve kterých přinesla mnoho úspor a přispěla k významnému zlepšení efektivity práce. Jako příklad lze uvést četné redakční systémy určené pro správu a úpravu obsahu právě webových stránek nebo systémy pro monitorování dostupnosti. Na druhou stranu je tato platforma často brána jako všelék, který nemá problémy plnohodnotných aplikací, což rozhodně není a v dohledné době určitě nebude pravdou. Jako špatné příklady slouží například data-sharing portály nebo fakturační systémy kompletně ovládané přes web.


Bezpečnostní rizika při tvorbě webových aplikacích lze rozdělit do třech hlavních kategorií:

• špatné programovací postupy,
• chybná analýza,
• nedostatky webových prohlížečů.

Daly by se vést dlouhé diskuse na téma, která z těchto kategorií představuje větší riziko. Každopádně lze říci, že první dvě kategorie máme jako tvůrci softwaru možnost přímo ovlivnit. Programátory lze školit, analytici mohou být konfrontováni s bezpečnostní analýzou svých návrhů a i kvalitní management softwarového vývoje může napomoci správně klasifikovat možná rizika. Třetí kategorie je jakousi perličkou navíc a je potřeba jí pravidelně věnovat pozornost při uvádění webových aplikací do provozu i v rámci běžného servisu. Pojďme se nyní podívat na jednotlivé kategorie zblízka.

Špatné programovací postupy

V posledních deseti až patnácti letech se hodně rozšířily jednoduché skriptovací jazyky, které byly původně určeny k automatizaci relativně malých problémů. Časem je ale programátoři začali používat na všechno, co si lze představit – tedy i na programování webových aplikací. Tyto jazyky pochopitelně postrádaly možnosti, jak efektivně psát bezpečné aplikace, a často dodnes vidíme na aplikačních frameworcích psaných pro tyto jazyky, že „bezpečnost“ je do nich roubována jen velmi těžko.
Nejčastějším – či spíše v médiích nejvíce viditelným – jazykem pro psaní webových aplikací je jazyk PHP. Vznikl jako jednoduchý nástroj pro přidání dynamiky do jinak statických webových stránek a neduhy ze své počáteční jednoduchosti si nese dodnes. Ostatně zkratka PHP původně znamenala Pretty Home Pages.
Snadná syntaxe a dostupnost tohoto jazyka mají za následek, že PHP programátorem se může stát kdokoliv takřka přes noc. Má to i své světlé stránky, najmout PHP programátora dnes není nijak velká investice a firmy mají jistotu, že vždy mohou snadno sehnat náhradu. Najmout dobrého PHP programátora ale už tak laciné není a velmi rychle se ukáže, že když je potřeba naprogramovat komplexní systém, je nutné použít sofistikované prostředky a kvalifikované programátory, jejichž náklady je třeba zahrnout do rozpočtu.
Mnohokrát by při tom stačilo poskytnout programátorskému týmu jako celku patřičné školení o rizicích spojených s programováním webových aplikací a naučit je základním návykům bezpečných programovacích postupů. Špatných programovacích postupů je sice neomezeně mnoho, v praxi se ale setkáváme jen se spoustou variací na některé základní.
Tyto problémy se samozřejmě netýkají jen programovacího jazyka PHP. Většina zde popsaných problémů je spíše velmi obecného charakteru a lze je vidět i při vývoji webových aplikací v programovacích jazycích, jako je Java, Python, C# či dnes populární Ruby.
Nejčastějším programátorským opomenutím je špatná, či žádná kontrola hodnot proměnných nebo jejich chybějící inicializace. Tento neduh umožňuje útočníkovi získat přístup k informacím, které nebyly určeny ke zveřejnění. Takto lze získat přístup k systémovým souborům, ke zdrojovým kódům aplikace, nebo dokonce podstrčit potenciálně škodlivý kód.
Typickou ukázkou takovéto chyby je přístup k souborům, mějme například následující hypotetický fragment publikačního systému, soubor „zobraz.php“:

include(„top.html“);
include(„data/“.$soubor);
include(„bottom.html“);

Tento soubor je využit k zobrazení souboru v adresáři „data“, mohou v něm být například články, zobrazované pod URL:

http://domena.cz/zobraz.php?soubor=bezpecne-programovani.html

Zneužití je na místě, pomocí techniky zvané path-traversal je možné zobrazit si obsah libovolného souboru na filesystemu, ke kterému má webserver přístup, stačí jako proměnnou soubor podstrčit například „../database.cfg“ a máme k dispozici obsah souboru, ve kterém bude pravděpodobně konfigurace přístupu do databáze včetně uživatelského jména a hesla.
Odhlédneme-li od faktu, že tento přístup k programování webových aplikací by v dnešním světě neměl mít místo, lze si představit korektní verzi, která bude kontrolovat, zda se snažíme zobrazit soubor z povoleného umístění a zda jméno souboru neobsahuje nějaké potenciálně nebezpečné znaky. Zde se jedná o typickou ukázku technik bezpečného programování „input validation“ a „input sanitizing“.
Pokud by skutečně bylo potřeba zobrazovat obsahy fyzických souborů, je lepší mít někde uložené mapování identifikátorů na názvy souborů a od uživatele číst pouze daný identifikátor. Zcela tím zamezíme styku proměnné, kterou má uživatel možnost ovlivnit, přímo se souborovým systémem.
Sama o sobě nepředstavuje tato technika v dnešní době až tak velké riziko, neboť programovací frameworky poskytují bezpečná rozhraní přístupu k datovým úložištím – ať již k databázím, nebo souborům na disku. Programátoři ale často žádné takové rozhraní nepoužívají. Pro přístup k databázím by dnes již mělo být samozřejmostí použít nějaké rozhraní typu DBI, které obalí konkrétní SQL server sadou funkcí zajišťující bezpečné předání potenciálně nebezpečného obsahu.
Pokud by všechny systémy, se kterými se na webu můžeme setkat, využívaly rozhraní DBI, mohly by útoky typu SQL injection být minulostí. Dnes již klasický příklad může vypadat jako úprava nám známého „zobraz.php“:

echo(mysql_fetch(mysql_query(„SELECT data FROM clanky WHERE id=$soubor“))[0]);

Zde se nabízí SQL injection v celé své kráse. Pokud za proměnnou soubor dosadíme kus SQL příkazu, můžeme provádět zajímavé operace přímo v SQL serveru. Například „1; DELETE FROM clanky“, což je příkaz, který vyprázdní tabulku článků. Při tomto nezabezpečeném přístupu stačilo ukončit příkaz znakem středníku a napsat za něj libovolný další. Pochopitelně v reálném nasazení je to trošku složitější, ale opravdu jen o málo.
Celkově lze říci, že většinu programátorských chyb lze eliminovat buď dodržováním zásad bezpečného programování, nebo použitím již existujících komponent. Právě ona nechuť použít již hotové komponenty má často za následek uspěchanou a nekvalitní implementaci komponent vlastních, při snaze dodat výsledný produkt v co nejkratším termínu.

Chybná analýza

Při analýze zadání projektu a přípravy implementačních prací je možné předejít celé škále možných bezpečnostních rizik, nebo naopak otevřít „zadní vrátka“ případným útočníkům. Již ve fázi analýzy je potřeba rozhodnout, jakým způsobem se budou autentizovat privilegovaní uživatelé a jak budou ukládána a zpracovávána data sezení. Tyto dvě oblasti jsou obvyklým zdrojem nejhorších chyb a největších bezpečnostních rizik.
Pokud není dobře navržena autentizace uživatelů, znamená to, že je možné ji nějak přímo či nepřímo obejít. Zaprvé je dobré vyžadovat zabezpečenou transportní vrstvu, tedy použít protokol HTTPS a pořídit pro server důvěryhodný certifikát. Zadruhé je potřeba myslet na zachování důvěrnosti přihlašovacích údajů. V dnešní době především uživatelského jména a hesla.
Dnes se uživatelské jméno a heslo používají jako přihlašovací údaje jen ze setrvačnosti. K dispozici jsou již mnohem bezpečnější metody autentizace na základě kryptografie pomocí privátních a veřejných klíčů.
U autentizace heslem je potřeba brát v potaz i způsob, jakým budou data po uživateli vyžadována. Především je potřeba se zaměřit na zamezení možnosti podvrhnutí přihlašovacího formuláře pomocí technik typu cross-site scripting či man in-the-middle. Metoda cross-site scripting je o to nebezpečnější, že nevyžaduje téměř žádnou interakci od oběti útoku. Útočník pomocí zjištěného nedostatku v systému nahradí přihlašovací dialog svým vlastním, který údaje nic netušícího uživatele odešle na jeho vlastní server a poté zajistí, aby systém uživatele přihlásil a ten neměl možnost nijak poznat, že jeho heslo někdo zachytil.
Způsob zpracování sezení je zase důležitý z hlediska zachování důvěrnosti celé práce se systémem. Při některých nedostatcích návrhu je možné provést takzvaný útok typu session-steal, kdy útočník získá údaje, které mu umožní vystupovat v systému jako jiný, již přihlášený uživatel. Často k tomu stačí odchytit hodnotu identifikátoru sezení (session id) a tu poté použít na jiném počítači. Tomuto typu útoku lze efektivně předcházet relativně snadno – pokud vynecháme třetí kategorii problémů, na kterou se podíváme v závěru –, stačí zajistit bezpečné komunikační kanály a uvědomit si, že celek je tak bezpečný, jak je bezpečná jeho nejslabší část. I proto je dobré nemít přihlašovací formulář na stránce, jejíž obsah může být modifikován někým jiným než administrátorem systému.

Nedostatky webových prohlížečů

I když vaše webová aplikace bude dobře navržená a implementovat ji budou programátoři s dobrými znalostmi bezpečných programovacích technik, jsou zde rizika, která nelze přímo ovlivnit. Webový prohlížeč je multifunkční aplikace, která dnes již zdaleka neslouží jen k prohlížení statických webových stránek, používá se k celé řadě činností, od provádění bankovních transakcí po sledování multimédií. Mnoho nových vlastností s sebou přineslo mnoho nových možností zneužití. Častými chybami prohlížečů je dnes nedostatečné oddělení oprávnění jednotlivých domén a/nebo stránek. Ať už se jedná o práva pro přístup k uloženým cookies, nebo přímo k obsahům stránek načtených v jiných oknech či záložkách prohlížeče.
Některé chyby ve webových prohlížečích usnadňují již známé útoky. Především se jedná o možnosti podvrhnutí legitimní stránky stránkou útočníka, nebo ještě hůře, usnadnění útoku typu session-steal. Například při nedostatečném vynucování oprávnění přístupu ke cookies je možné vyžádat si cookie z cizí domény či cizí stránky a poslat jej na počítač ovládaný útočníkem. Často prosté oddělení na domény a stránky nestačí, neboť je nutné počítat i s útočníkem, který má práva zápisu do nějaké „nevýznamné“ části webu, jako je diskusní fórum či publikace článků. Pokud zkombinujeme tuto možnost se současným způsobem správy cookies – tedy podle domén a stránek, a ne podle „sezení“ v rámci prohlížeče –, je snadné ukrást cookie obsahující session id přihlášeného uživatele.
Tyto problémy je potřeba řešit důslednější kontrolou na straně serveru, a nespoléhat se tedy na oddělení práv na straně webového prohlížeče.

Prevence a obrana

Pokud chceme v krátkosti shrnout problémy, se kterými se při současném vývoji webových aplikací setkáváme, dojdeme k závěru, že se jedná o stále se opakující variace na jedno téma: neinformovanost. Programátoři nepoužívají bezpečné programovací techniky a univerzální rozhraní, protože o nich nevědí nebo neznají jejich přínos. Analytici jsou schopni perfektně vytvořit obraz požadavků zákazníka, ale již selhávají ve volbě správných prostředků k dosažení cíle. V obou případech by pravděpodobně stačila krátká série školení a výsledek by byl téměř okamžitý.
A v případě, že si nejsme bezpečností provozované aplikace jisti, je možné nakonfigurovat HTTP server a interpret skriptovacího jazyka – či programové prostředí systému – tak, aby bylo některým útokům zabráněno. Lze omezovat možnosti otvírání souborů jen na některé části souborového systému, práva, co smí webová aplikace spouštět, a mnoho dalších velmi jemných nastavení.
Co dělat, pokud již máte v provozu systém, který se stal obětí úspěšného útoku hackera? Nejprve je dobré nechat provést analýzu napadeného systému a pokusit se přesně zjistit, kterou chybu a jakým způsobem útočník zneužil. Také je vhodné nechat provést bezpečnostní analýzu zdrojových kódů a návrhu aplikace nezávislým auditorem, který může poradit konkrétní kroky k efektivní nápravě.