Hlavní hrozby pro firemní web

„Zcela to ignorují,“ říká IT konzultant Joel Snyder. „Co se týče týmu pro návrh webu, hledají se kreativní lidé, kteří vytvoří zajímavé stránky… To je hlavní prioritou a zabezpečení webů je někde na zadním místě seznamu. Největší problém přitom spočívá v tom, že návrháři nevytvářejí uvnitř webových aplikací bariéry, které by umožnily rozdělení a validaci dat při přenosu mezi částmi systému.“

„Zabezpečení je obvykle něco, co se řeší spíše až po vytvoření webu, než před jeho návrhem,“ souhlasí Khalid Kark, analytik společnosti Forrester. „Jsem přesvědčen, že většinu webů lze hacknout,“ dodává. „Jádrem potíží je to, že zabezpečení není nedílnou součástí návrhu aplikace.“ Jedním ze subjektů, které se snaží vyřešit tento nesoulad, je nezisková organizace OWASP (Open Web Application Security Project). Nedávno mimo jiné vydala zprávu „Deset nejzávažnějších chyb zabezpečení webových aplikací“, která by měla zvýšit povědomí o největších problémech zabezpečení, které musejí vyřešit weboví vývojáři.

První verze tohoto seznamu byla přitom vydána v roce 2004, ale vedení organizace tvrdí, že zabezpečení webů se dosud příliš nezlepšilo. Nové prvky, jako jsou například Ajax a bohaté internetové aplikace (RIA), které umožňují vylepšit vzhled webů, také vytvářejí více možností pro útok, jak dodává Kark. Přesvědčit podnikatele, že jejich weby nejsou zabezpečené, přesto není snadné.

„Je to pro mne frustrující, protože chyby v zabezpečení je velmi snadné nalézt, a tedy i zneužít,“ říká Jeff Williams, zakladatel společnosti Aspect Security. „Je to jako chybějící zeď domu.“ Přinášíme vám proto souhrn deseti nejdůležitějších chyb zabezpečení webů uváděných organizací OWASP, včetně popisu každého problému, příkladů ze života a návodu k odstranění těchto nedostatků.

1. Cross site scripting (XSS)
- Problém: Nejobvyklejší a nejběžnější chyba 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 unést uživatelské relace, znetvořit webové stránky, vložit nepřátelský obsah č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. V nejhorším scénáři může hacker ukrást informace a vydávat se na webových stránkách banky za oprávněného uživatele, jak varuje Snyder.

- Příklad ze života: PayPal se nedávno stal terčem útoku, při kterém útočníci přesměrovali návštěvníky webu této organizace na stránku s upozorněním, že jejich účty jsou ohroženy. Oběti byly přesměrovány na phishingový server a požádány o zadání přihlašovacích údajů k účtu PayPal, čísla SSN (slouží k identifikaci osob v USA) a podrobné údaje o kreditních kartách. Společnost Pay-Pal už chybu samozřejmě opravila.

- Jak chránit uživatele: Používejte seznam typu whitelist k validaci všech příchozích dat, který umožní odmítnout veškerá data nespecifikovaná jako správná. Tento přístup je opakem seznamu blacklist, který odmítá veškeré nežádoucí vstupy. Navíc nasazuj-te vhodné šifrování všech výstupních dat. „Validace umožňuje odhalit útoky a šifrování zase chrání před všemi pokusy o vložení nežádoucího skriptu přímo v prohlížeči,“ uvádí OWASP.

2. Injection flaw
- Problém: Pokud jsou data od uživatele odesílána do interpreterů (komponenta, která interpretuje příkazy zadané v textové podobě) jako součást příkazu nebo dotazu, zkoušejí je hackeři oklamat tak, aby nekontrolovaně vykonaly jejich příkazy. „Tyto chyby umožňují útočníkům vytvářet, číst, aktualizovat a smazat jakákoli v aplikaci dostupná data,“ uvádí OWASP. „V nejhorším případě umožní tyto chyby zabezpečení útočníkovi zcela poškodit aplikaci a nosné systémy, a to dokonce i ty, které jsou ukryty hluboko za firewallem.“

- Příklad ze života: Ruští hackeři se v  roce 2006 vlámali do vládního webu Rhode Islandu za účelem ukrást data o kreditních kartách. Sami tvrdí, že pomocí útoku SQL injection (vložení příkazů do dat pro SQL) ukradli 53 tisíc čísel kreditních karet, zatímco poskytovatel hostingových služeb tehdy prohlásil, že jich bylo pouze 4 113.

- Jak chránit uživatele: Nepoužívejte interpretery, je-li to možné. „Pokud interpreter musíte použít, je zásadní metodou ochrany před útokem vkládáním použití bezpečných rozhraní API. Patří mezi ně například dotazy se silně typizovanými parametry a knihovny objektově relačního mapování (object relational mapping),“ uvádí OWASP.

3. Spuštění škodlivého souboru
- Problém: Hackeři mohou vzdáleně spustit kód, vzdáleně nainstalovat rootkity nebo zcela poškodit systém. Jakýkoli typ webové aplikace je zranitelný, pokud akceptuje názvy souborů nebo soubory od uživatelů. Tato chyba zabezpečení je nejběžnější u PHP, který je široce používaným skriptovacím jazykem pro vývoj webů.

- Příklad ze života: V roce 2002 zjistil velmi mladý programátor, že web Guess.com je zranitelný vůči útokům, které by mohly umožnit krádež záznamů více než 200 tisíc zákazníků z databáze Guessu, a to včetně jmen, čísel kreditních karet a dat jejich expirace. Společnost přislíbila modernizovat zabezpečení následující rok, když byla vyšetřována úřadem Federal Trade Commission.

- Jak chránit uživatele: Nepoužívejte vstupy od uživatelů v žádném souboru serverových zdrojů, jako jsou obrázky či části skriptů. Nastavte pravidla firewallu pro zabránění novým připojením k externím webovým serverům a k interním systémům.

4. Nezabezpečené přímé odkazy na objekty
- Problém: Útočník změní přímé odkazy na objekty, aby získal neoprávněný přístup k dalším objektům. To se stává, pokud adresy URL nebo parametry formulářů obsahují odkazy na objekty, jako jsou soubory, adresáře a databázové záznamy či klíče.

Webové servery bank obvykle používají číslo účtu zákazníka jako primární klíč, a mohou tak vyzradit čísla účtů ve webovém rozhraní. „Odkazy na klíče databází jsou často vystaveny,“ uvádí OWASP. „Útočník tyto parametry může využít k útoku jednoduchým hádáním nebo hledáním dalšího platného klíče. Často mají obyčejnou sekvenční podobu.“

- Příklad ze života: V roce 2000 byl hacknut web australského finančního úřadu uživatelem, který změnil DIČ obsažené v adrese URL, a získal tak přístup k údajům o 17 tisíc společnostech. Hacker tyto firmy e-mailem upozornil na chybu v zabezpečení.

- Jak chránit uživatele: Používejte index, mapu nepřímých odkazů či jinou nepřímou metodu, abyste zabránili použití přímých URL na objekty. Není-li možné vyvarovat se přímých referencí, ověřte před jejich použitím oprávnění návštěvníků webu.

5. Podvržení požadavků mezi weby
- Problém: „Je jednoduchý a zničující – tento útok převezme řízení prohlížeče oběti během přihlášení k webu a odesílá škodlivé požadavky webové aplikaci. Weby jsou extrémně zranitelné částečně proto, že se pokoušejí ověřovat požadavky na základě souborů cookie dané relace nebo pomocí funkce „zapamatuj si mne“. Mezi potenciální cíle patří banky.

„99 % aplikací na internetu ne-odolá podvrhu požadavků mezi weby,“ říká Williams. „Došlo ke skutečnému zneužití, když ně-kdo přišel o peníze? Banky to zřejmě vůbec nezjistí. Těm se vše jeví jako legitimní transakce přihlášeného uživatele.“

- Příklad ze života: Hacker známý jako Samy získal koncem roku 2005 více než milion „přátel“ na webu MySpace.com pomocí červa, který automaticky přidával zprávu „Samy je můj hrdina“ na tisících stránek webu MySpace. Samotný útok nebyl moc škodlivý, ale byl proveden tak, aby předvedl sílu kombinace skriptování mezi weby a podvržení požadavků mezi nimi. Další příklad, který se stal před více než rokem, ukázal zranitelnost služby Google tím, že cizí weby mohly změnit jazyková nastavení uživatele služby Google.

- Jak chránit uživatele: Nespoléhejte na pověření či tokeny automaticky zasílané od prohlížečů. „Jediným řešením je používat vlast-ní token, který si prohlížeč nezapamatuje,“ uvádí OWASP.

6. Únik informací a nesprávné zpracování chyb
- Problém: Chybové zprávy, které aplikace generují a zobrazují uživatelům, jsou rovněž použitelné pro hackery, když narušují soukromí. Tyto zprávy totiž neúmyslně vyzrazují informace o konfiguraci programu i interním zpracování. „Webové aplikace často odhalují data  o svém interním stavu prostřednictvím podrobných nebo ladicích chybových hlášení. Nezřídka lze tyto údaje využít k zahájení nebo k zautomatizování silnějších útoků,“ uvádí OWASP.

- Příklad ze života: Únik informací snadno nastává po zpracování chyby. Bývá zaznamenán také po výskytu chyb zabezpečení, kdy jsou důvěrná data ponechána zcela na odiv. Debakl společnosti ChoicePoint začátkem roku 2005 spadá zhruba do této kategorie. Záznamy 163 tisíc zákazníků byly vyzrazeny poté, co si zločinci vydávající se za legitimní zákazníky organizace ChoicePointu vyhledali podrobnosti o jednotlivcích uvedené v databázi personálních informací této organizace. ChoicePoint následně omezil prodej produktů obsahujících důvěrná data.

- Jak chránit uživatele: Používejte testovací nástroj, jako je například WebScarab Project od organizace OWASP, k zobrazení chyb, které generuje aplikace. „Aplikace, které nebyly testovány tímto způsobem, budou téměř jistě generovat nečekaná chybová hlášení,“ uvádí OWASP.

- Další tip: Zakažte nebo omezte podrobná hlášení o chybách a nezobrazujte uživatelům ladicí informace.

7. Porouchané ověřování a správa relací
- Problém: Pokud aplikace selže při ochraně relací a pověření, může dojít ke  krádeži uživatelských a administrátorských účtů. Dávejte pozor na narušení soukromí nebo funkční omezení řízení oprávnění a zodpovědnosti. „Chyby v hlavním mechanizmu ověřování nejsou vzácné, ale nedostatky se častěji vyskytují ve formě slabých pomocných funkcí ověřování, jako je přihlašování, odhlašování, správa hesla, časový limit, funkce „zapamatuj si mne“, tajné otázky a aktualizace účtu,“ uvádí OWASP.

- Příklad ze života: Společnost Microsoft musela v roce 2002 odstranit chybu zabezpečení služby Hotmail, která dovolovala tvůrcům škodlivého kódu JavaScriptu ukrást uživatelská hesla. Tato chyba byla zjištěna prodejcem síťových produktů a e-mailům obsahujícím trojské koně dovolovala změnit uživatelské rozhraní služby Hotmail a nutit uživatele k tomu, aby několikrát zadali své heslo, které bylo bez jejich vědomí odesláno hackerům.

- Jak chránit uživatele: Komunikace a úložiště ověřovacích údajů musejí být zabezpečené. Protokol SSL pro přenos privátních dokumentů by měl být jedinou možností komunikace pro části aplikace podléhající ověřování, přičemž citlivé údaje by měly být uloženy v hašované nebo šifrované podobě.

- Další tip: Zbavte se vlastních souborů cookie používaných k ověřování a správě relací.

8. Nezabezpečené kryptografické úložiště
- Problém: Mnoho webových vývojářů  důvěrná data v úložištích nešifruje, přestože je kryptografie důležitou součástí většiny webových aplikací. Ale i když je šifrování použito, je často navrženo nedostatečně a využívá nevhodné šifry. „Tyto chyby mohou způsobit vyzrazení důvěrných dat a umožnit narušení,“ uvádí OWASP.

- Příklad ze života: Nedávný únik dat společnosti TJX vyzradil 45,7 milionu čísel kreditních a debetních karet. Průzkum kanadské vlády kritizuje firmu TJX za to, že neupgradovala svůj šifrovací systém předtím, než se stala cílem elektronického odposlouchávání, které začalo v červenci 2005.

- Jak chránit uživatele: Kromě jiného generujte klíče off-line a nikdy nepřenášejte privátní klíče přes nezabezpečené kanály.

9. Nezabezpečená komunikace
- Problém: Podobně jako u bodu 8 se jedná o nesplnění požadavku šifrovat kvůli ochraně důvěrné komunikace síťové přenosy. Útočníci mohou přistupovat k nechráněným konverzacím, včetně přenosů pověřovacích dat a důvěrných informací. Z tohoto důvodu například normy pro karetní transakce požadují šifrování informací o kreditních kartách přenášených přes internet.

- Příklad ze života: Opět společnost TJX. Vyšetřovatelé se domnívají, že ke krádeži dat bezdrátově přenášených mezi přenosnými zařízeními pro kontrolu ceny, pokladnami a počítači obchodů použili hackeři teleskopickou anténu a notebook, jak píše Wall Street Journal. „Bezdrátová síť za 17,4 miliardy dolarů patřící prodejnímu řetězci byla méně zabezpečená než sítě většiny domácností,“ napsal deník. TJX například používal šifrování WEP namísto robustnějšího WPA.

- Jak chránit uživatele: Nasaďte  šifrování SSL při každém ověřovacím spojení i během přenosů citlivých dat, jako jsou uživatelská pověření, podrobnosti o kreditních a platebních kartách, zdravotní záznamy a další privátní informace. SSL nebo podobný šifrovací protokol by také měl být využit ke klientskému, partnerskému, zaměstnaneckému i administrativnímu přístupu k firemním on-line systémům. Aplikujte zabezpečení na transportní vrstvě nebo šifrování na úrovni protokolu k ochraně komunikace mezi součástmi infrastruktury, jako jsou webové servery a databázové systémy.

10. Nefunkční omezení přístupu k adrese URL
- Problém: U některých webových stránek se očekává omezení přístupu pouze na malou skupinu privilegovaných uživatelů, jako jsou například správci. Často však tyto stránky nemají žádnou skutečnou ochranu a hackeři mohou adresu zjistit pomocí inteligent-ního hádání. Řekněme, že adresa URL odkazuje na číslo ID „123456“. Hacker si může říci „A copak najdu na ID 123457?“ vysvětluje Williams.

Útoky zaměřené na tuto chybu zabezpečení jsou nazývané vynucené prohlížení (forced browsing) a zahrnují hádání odkazů a techniky využití hrubé síly k nalezení nechráněných stránek,“ jak uvádí OWASP.

- Příklad ze života: Bezpečnostní díra na webu konference Macworld Conference & Expo minulý rok umožnila uživatelům získat vstupenky „Platinum“ za téměř 1 700 dolarů a zvláštní přístup na přednášku Steva Jobse, vše zdarma. Chybou byl kód, který ověřoval privilegia na klientském počítači, nikoliv však na serveru. To umožnilo získat lidem vstupenky prostřednictvím JavaScriptu v prohlížeči namísto serveru.
 
- Jak chránit uživatele: Nepředpokládejte, že se uživatelé nedozvědí o tajných adresách URL. Všechny tyto adresy a služby podniku by měly být chráněny účinným mechanizmem pro řízení přístupu, který dostatečně ověří roli a privilegia uživatele.