Hrozby pro webové aplikace

Téměř sedmdesát procent útoků je provedeno na aplikační vrstvu. Toho by si měli být vědomi vývojáři a architekti a měli by nové systémy navrhovat s ohledem na aktuální bezpečnostní hrozby. Pokud je k bezpečnostním hrozbám přistoupeno seriózně již při návrhu a implementaci, riziko prolomení takové aplikace se rapidně snižuje. Bohužel často se uplatňuje spíše scénář, kdy co největší nabídka funkcí, honba za dostupností a snaha vytvořit „co nejzajímavější web“ odsunou otázky bezpečnosti kamsi do pozadí vývoje a tyto se začnou řešit v lepším případě, až když je aplikace nasazená.

Případ A: otázky zabezpečení řešíme již při návrhu a testování aplikace

Při řešení tohoto úkolu nejsme naštěstí ponecháni zcela napospas vlastním analýzám, testům a pokusům. Dobře etablovaná organizace The Open Web Application Security Project (OWASP) se již několik let zabývá monitoringem bezpečnostních hrozeb webových aplikací. Asi nejznámějším výstupem činnosti této organizace je seznam nejčastějších chyb v zabezpečení webů společně s řešením daného problému. Ty nejčastější a nejzávažnější si zde rozebereme.

Cross site scripting (XSS)

Jde o nejběžnější chybu zabezpečení webových aplikací. XSS vznikne v okamžiku, kdy aplikace odesílá uživatelská data webovému prohlížeči, aniž by nejprve tento obsah ověřila nebo zašifrovala. To umožní hackerům spustit škodlivé skripty v prohlížeči a číst uživatelské relace, změnit webové stránky či řídit phishingové a malwarové útoky. Útoky jsou obvykle vykonávány prostřednictvím JavaScriptu, který umožňuje hackerům manipulovat s jakoukoli vlastností stránky.
Jak ochránit aplikaci: Například použitím seznamu typu whitelist k validaci všech příchozích dat, který umožní odmítnout veškerá data nespecifikovaná v tomto seznamu jako nesprávná. Tento přístup je opakem seznamu blacklist, který odmítá veškeré jmenované nežádoucí vstupy. Další možností je při vkládání dat od uživatele do HTML stránky odfiltrovat „nebezpečné“ znaky z uživatelského vstupu, respektive je převést na příslušné HTML entity (< za <, > za > atd.), na což lze použít dostupné funkce (např. v jazyce PHP je to funkce htmlspecialchars). Ve formulářích, chatech a jiných prvcích, kde může uživatel vložit svůj vstup, zakázat používání HTML značek (což ale není možné vždy). Nic nezkazíte také zavedením tzv. CAPTCHA kódu, který je uživatel nucen vyplnit před odesláním formuláře. Pravdou totiž je, že většina skutečných útoků na stránky se děje plně automatizovaně pomocí robotů. Přítomnost obrázkového kódu robotovi znemožní odeslání obsahu formuláře na váš server.

Injection flaw

Data jsou od uživatele odesílána do aplikace a následně zpracována pomocí interpreterů (interpreterem může být například PHP nebo MySQL) jako součást příkazu nebo dotazu. Tato data zkoušejí hackeři pozměnit tak, aby nekontrolovaně vykonaly jejich příkazy. Tyto chyby pak umožňují útočníkům vytvářet, číst, aktualizovat a mazat jakákoli v aplikaci dostupná data. V horším případě získají takto útočníci přístup až do provozních systémů ukrytých za firewallem.
Jak ochránit aplikaci: Nepoužívejte interpretery, je-li to možné. Pokud se však použití interpreteru nelze vyhnout, je řešením použití určitého mezistupně v komunikaci mezi aplikací a samotným interpreterem – například vlastní rozhraní API (application programming interface), které bude mít vlastní velmi typizovanou syntaxi a přesně definovanou sadu příkazů, které pomocí něj budou moci být odeslány na server.

Únik informací a nesprávné zpracování chyb

Chybové logy, které aplikace generují a zobrazují uživatelům, jsou rovněž použitelné pro hackery, a to zejména při sběru informací o cíli. Tyto zprávy totiž vyzrazují informace o konfiguraci softwaru a potažmo i serveru.
Řešení: Organizace OWASP doporučuje testovat chybové výstupy systémů jejich aplikací WebScarab Project (volně dostupná). Toto testování odhalí všechna očekávaná i neočekávaná chybová hlášení, a především prozradí konkrétní obsah chybových hlášek, které by mohly znamenat potenciální hrozbu. Další možností je chybová hlášení zcela zakázat. To ale nelze vždy aplikovat. Příkladem může být webhostingový server, na kterém zákazníci hostují a zároveň ladí své aplikace. V tomto případě se poskytnutí výpisu chyb asi nevyhneme. Naštěstí existují další metody (viz bezpečnost serverů), které lze v takovém případě nasadit.

Případ B: otázky zabezpečení řešíme až po objevení problému, nebo úspěšném útoku na web

Řešením je v tomto případě buď nasazení rychlé bezpečnostní záplaty, nebo použití nějakého dalšího externího bezpečnostního systému, který nezasahuje přímo do aplikace jako takové. První řešení je samozřejmě lepší, ale bohužel ne vždy ho můžeme aplikovat dostatečně rychle a pružně. Nasazení by například znamenalo neúměrně dlouhý výpadek aplikace, navíc by mohlo být spojeno s dalšími nutnými úpravami, a tedy dalšími náklady.
Co se týče „externí“ možnosti ochrany aplikace, jsou v dnešní době velmi často nasazovány tzv. WAF (web application firewall) systémy. WAF může být ve formě softwaru přímo na serveru, nebo také jako samostatné hardwarové zařízení, které je umístěno mezi klientem a serverem. Tyto systémy dokáží na základě definované sady pravidel (core rules), která je předdefinovaná ve většině případů již výrobcem, analyzovat veškerý provoz, který server přijímá přes HTTP a jiné protokoly. V praxi to tedy znamená, že i když „děravá“ aplikace propustí závadný kód (například pozměněný XSS útokem) WAF toto dle databáze pravidel dokáže zachytit a takovýto dotaz (příkaz) na server nepropustit. Pro složitější definice pravidel mají WAF k dispozici vlastní skriptovací prostředí. Výhodou řešení WAF je prakticky nulová závislost na stávající infrastruktuře a aplikacích.

Hrozby pro servery

Můžeme říci, že bezpečnost serveru jde ruku v ruce s bezpečností aplikace, kterou hostuje. Pokud nemáme zabezpečenou aplikaci, otevíráme tak v podstatě útočníkům dveře k celému serveru. Asi nejznámější metody „zabezpečení“ serverů jsou firewally a další různé IDP/IPS (systémy detekce a prevence průniků). Co ale tyto systémy ve skutečnosti dělají?

Firewall

Stroze řečeno nedělá nic jiného, než že propouští/nepropouští komunikaci na zadaném portu. My ale chceme na svém serveru provozovat služby (proto jej také máme) z čehož logicky vyplývá, že určité porty prostě musí být otevřené.

IDS/IPS

Tyto systémy již sledují a v případě IPS i reagují na reálný provoz na síti, tedy na otevřených portech. Pokud IPS zaznamená například útok typu port scan, nebo DoS (denial of service), dokáže na základě sady definovaných pravidel na situaci pružně reagovat, a tedy nejen vyrozumět administrátory, ale i provést patřičnou akci (blokace IP, přesměrování provozu atd.).
Tento systém ochrany nám však selže v okamžiku, kdy útočník pošle škodlivá data přímo přes aplikaci (tedy využije neošetřený vstup – viz bezpečnostní problémy výše). Zde postupně selhávají jak firewall – port musí být otevřený, jinak by aplikace nepřijímala ani „správná“ data –, tak IPS – z pohledu IPS jde o legitimní datový tok. Pomoci nám tedy může již jen zmíněný WAF, nebo nejlépe odolnost samotné aplikace.
Samotný server by měl být zároveň nastaven tak, aby v případě prolomení všech výše zmíněných ochran, neměl by být přímo ohrožen jeho samotný chod (stabilita operačního systému). Uvažujeme-li linuxový server, máme hned několik možností (zdaleka nejsou uvedeny všechny):

Chroot kritické aplikace

Jde o metodu, kdy je aplikace „uzavřena“ ve vlastním kořenovém adresáři. Takováto aplikace pak nemá přístup do dalších adresářů (tedy ani k souborům). V případě napadení aplikace (tedy procesu) útočník nezíská přístup k celému serveru.

Limit maximálního počtu běžících procesů

Toto nastavení pomáhá předcházet tzv. fork bomb (v podstatě DoS útok). Napadením serveru a spuštěním škodlivého kódu by útočník mohl způsobit pád serveru vyvoláváním kopií stále stejného procesu, což by následně vedlo k vyčerpání paměti. Pokud by se toto přes veškerá opatření stalo, lze zmírnit následky nastavením maximálního počtu běžících procesů – typicky definováno v /etc/security/limits.conf.

Bezpečné nastavení PHP

Výše v článku jsem uvedl zmínku o specifiku webového serveru v souvislosti s vypisováním chyb. To samozřejmě může poskytnout útočníkovi citlivé údaje o nastavení serveru. Řešením je (pokud používáme v rámci Apace virtuální servery) omezit spouštění PHP skriptů pro daného uživatele pouze na konkrétní adresář. Tím i v případě nekalých praktik zabráníme kompromitování celého serveru.


Autor pracuje jako specialista technické podpory ve společnosti Ignum.