Je přitom třeba si uvědomit vážná rizika a jejich možné důsledky i v případech, kdy chyba ve vašich aplikacích sice neohrožuje přímo vaši firmu, ale kompromitace uchovávaných dat, nebo impersonace vašich klientů a zneužití jejich účtů pro ně může znamenat zásadní finanční ztráty a poškození dobrého jména. Málokterá firma chce být v tisku známá tím, že zapříčinila bankrot svých klientů.

Téma bezpečnosti webových aplikací se tak v posledních letech dostává stále více do popředí zájmu. Existuje celá řada metodologií a standardů pro psaní „bezpečných“ webových aplikací a firmy do této oblasti často investují nemalé částky ze svých ročních rozpočtů. Jak je tedy možné, že výsledky penetračních testů vytýkají stále stejné chyby a dokonce ani OWASP TOP 10, souhrn nejběžnějších typů webových zranitelností, se za posledních 10 let nijak významně nezměnil? Proč v dnešní době raketového rozvoje technologií narážíme na stále stejné chyby? Produktový pohled se totiž při vývoji webových aplikací přirozeně zaměřuje na výkonnost, efektivitu a uživatelský komfort. Aby aplikace běžela podle zadání klienta, v daném časovém rámci a za slíbené ceny. Přínos penetračních testů před nasazením aplikace do ostrého chodu tedy spočívá právě v pohledu zvenčí a z druhé strany, který umožňuje určit, jak lze danou chybu či funkcionalitu zneužít.

Jak to, že jsou ale aplikace zranitelné ačkoliv na nich pracují ti nejlepší vývojáři a samotná aplikace je precizně otestovaná? Zprovozněním aplikace v „dobrém stavu“ bohužel práce nekončí, ale začíná. Webové aplikace, je třeba řádně udržovat. Jinak, stejně jako auta, velmi rychle zastarávají.

Jak se i kvalitní aplikace stává během času nezabezpečenou?

Pojďme si tedy představit několik oblastí, které se v běžné praxi ukazují jako problematické z hlediska komplexního pohledu na bezpečnost:

Knihovny a doplňky

V kontrastu s pečlivostí vlastního vývoje se často setkáváme s hurá akcí při přidávání jednotlivých komponent, jako jsou například doplňky nebo používání knihoven bez jakékoli validace jejich obsahu, aktualizace verzí a kontroly již známých zranitelností. Je možné najít kus kódu na Githubu? Super. Je možné na první pohled funkční část zkopírovat ze Stackoverflow? Ještě lépe. Je ovšem tento kód důvěryhodný? Kdo nese za jeho bezpečnost odpovědnost? Zvlášť u kódu rozsáhlejšího charakteru není vždy snadné jednoduše vyhodnotit dopad na zbytek aplikace a tedy i potenciální bezpečnostní problém. Rozhodně se nesnažíme říct, že cílem by mělo být psaní vlastních knihoven. Nicméně ke všem externím zdrojům je třeba přistupovat s nedůvěrou a jejich výběr by měl podléhat schvalovacímu procesu.

Rozšíření aplikace a nedostatky v projektové dokumentaci

Obdobně jako při volbě komponent dochází k poměrně spontánním rozhodnutím i při rychlých opravách nebo dodatečném přidání komponent a funkcionalit. Tyto úpravy ale obvykle nejsou dostatečně otestovány v kontextu všech situací, které mohou nastat při používání nové funkcionality vzhledem k již implementovaným vlastnostem aplikace a často vedou k neočekávanému chování. A přesně to útočník potřebuje. Dochází při změně maintainera k důslednému předání potřebné dokumentace? Jsou všichni seznámeni se strukturou aplikace? Pravděpodobně ne, není čas. A chyba je na světě. Stejně tak, ačkoliv agilní vývoj aplikací má mnoho výhod, z pohledu bezpečnosti je stále vhodné nezapomínat na dostatečnou hloubku a aktualizace dokumentace a provedení vhodné analýzy.

Aktualizace a dependency kontroly

Nepodceňujte význam životního cyklu vaší aplikace. Vývoj technologií jde ruku v ruce s nalézáním nových zranitelností a způsoby jejich zneužití. Jak se říká, všechno je zranitelné a pokud není, tak to akorát ještě není veřejně známé. Provádíte při provozu webové aplikace kontroly závislostí? Ve chvíli, kdy kladete důraz na bezpečnost, je naprosto nezbytné průběžná kontrola nově nalezených zranitelností, které se mohou objevit ve verzích používaných komponent a včasná reakce formou aktualizace či změny dané komponenty. Zvlášť když je možné tyto kontroly zcela automatizovat díky řadě dostupných nástrojů. Souhlasíme s tím, že aktualizace jako taková není samospásná, či dokonce může novou bezpečnostní chybu vyvolat. Nicméně je smutné, když ke kompromitaci aplikace dojde kvůli chybě, která je jednak veřejně známá, jednak k ní existují i veřejně dostupné exploity. Neusnadňujte to útočníkům zbytečně, vždyť byt také nezamykáte klíčkem k dětské pokladničce.

Threat Modeling a penetrační testy, které mají smysl

Bezpečnostní testování webových aplikací a portálů, testy infrastruktury, testy fyzické bezpečnosti, phishingové kampaně...Ano, možností je mnoho a penetrační testy se mohou pořádně prodražit. Má ovšem tak rozsáhlé testování vůbec smysl? Ano i ne. Samotný test webové aplikace, jakkoliv nákladný či důkladný, stále nemusí přinést očekávané výsledky v podobě celkového zvýšení úrovně bezpečnosti vaší společnosti. Na bezpečnost je totiž vždy nutné nahlížet jako na celek. Koneckonců, je vlastně jedno, zda útočník získá hesla technickou cestou injektováním databáze, nebo pomocí metod sociálního inženýrství přímo od zaměstnance. Na druhou stranu vhodný Threat Modeling a identifikace klíčových assetů spolu s analýzou možných vektorů, jak může k ohrožení daného assetu dojít, může společnosti ušetřit řadu nákladů i stresu z potenciálních bezpečnostních incidentů.

Klasický model penetračního testu lze samozřejmě doplnit např. i vhodně zvoleným Bug Bounty programem a odměnit jen úspěšné „lovce“. Koneckonců, vždycky je lepší nahlášená zranitelnost než ta, o které nevíte. Na co si ale dát pozor? Především na rozsah, cíl a přesné podmínky vyplacení odměny. Přeci jen nikdy nevíte, kdo se do takového programu zapojí a mohli byste být nepříjemně překvapeni.

Chyby vzniklé opravou a proč nezapomínat na opakovaný test

Společnosti si často neuvědomují dodatečné náklady (jak finanční, tak především časové), které je nutné zohlednit před začátkem bezpečnostního testování. Test totiž pravděpodobně nebude bez nálezů a opravám je třeba se důsledně věnovat. Pojďme se zamyslet nad tím, jak vypadá takový klasický scénář po reportování nalezených zranitelností. Klient dostane výsledný report, hodí ho na hlavu svému dodavateli a dodavatel, který z pochopitelných důvodů nemá radost, se snaží chyby pod tlakem klienta co nejrychleji opravit. A přesně tak vznikají další, často i závažnější chyby. Všechny opravy by měly být provedeny s rozmyslem v souladu s vedenou dokumentací a stavem zbytku aplikace. Stejně tak je třeba vyhnout se opravám ve formě „překrytí“ problému místo jeho řešení, jako je například úprava nedostatečné validace vstupů jednoduchým blacklistem. Velmi vhodné je po aplikaci jednotlivých oprav provést kontrolu aplikovaných změn, která často v celkových nákladech tvoří zanedbatelnou položku, ovšem představuje velkým přínos a vhodné zakončení bezpečnostního testu.

SIEM a sledování provozu

Na pomyslné druhé straně penetračních testů, které více či méně simulují útok, stojí interní bezpečnostní monitoring a způsob vyhodnocování případných incidentů. Vždycky je třeba počítat s možností, že může dojít ke kompromitaci i pečlivě napsané aplikace. Vhodně nastavený bezpečnostní monitoring vám umožní rychlou reakci na celou řadu incidentů, jako např. úspěšné pokusy o hádání hesel, včasná detekce počínajícího DDos útoku nebo detekci shellcode či laterálních pohybů. Stejně tak je ovšem nezbytné i vhodné logování v dostatečném detailu a dobou retence. Vždyť, pokud nemáte nad aplikací kontrolu, lze ji vůbec považovat za bezpečnou? Obdobně nelze nezmínit i vhodnou a především kontrolovanou segmentaci sítě, důsledně nastavená systémová oprávnění a šifrování úložišť a záloh.

Shrnutí

Výše uvedené je samozřejmě pouze krátkým výčtem oblastí, kterým je vhodné v průběhu životního cyklu webových aplikací věnovat pozornost. Jistě není třeba zmiňovat, že přístup ke každé aplikaci, vzhledem k jejímu účelu a rizikovosti, bude velmi individuální. Pojďme se nicméně dát předsevzetí, že se v roce 2020 pokusíme dívat na bezpečnost přece jen v trochu širším měřítku než dosud. Koneckonců, dejme hackerům šanci přijít konečně s něčím novým :).

Klára Szvitková Autorka článku se zabývá penetračními testy ve společnosti Etnetera a.s.