Vývoj bezpečných webových aplikací

Počet úspěšně provedených útoků na webové aplikace neustále roste – v současnosti se jedná o celosvětově nejrozšířenější formu napadení organizací. Zároveň jsou s ohledem na aktuální hospodářskou situaci více než kdy dříve uplatňovány tlaky na snižování finančních výdajů firem, což samozřejmě není nejlepší zpráva pro bezpečnost jimi provozovaných webových aplikací. Anebo je možné i této situace nějak využít?

Poskytování služeb napříč internetem skrze internetový prohlížeč uživatele se stalo jednoznačným trendem posledních let. Webové aplikace totiž umožňují svým vlastníkům dosáhnout jak výrazných úspor nákladů, tak i stále kvalitnějšího poskytování služeb, uživatelé naopak profitují z toho, že se dostanou k webovým řešením kdykoli a odkudkoliv. Statistiky bezpečnostních firem jsou však neúprosné: webové aplikace představují pro jejich vlastníky rizika zásadního charakteru, jež jsou ale často neúměrně podceňována a v mnoha případech o nich provozovatelé ani nevědí.

Zveřejňované informace o útocích na webové aplikace lze přitom porovnat s výsledky penetračních testů. Například za minulý rok „kritická“ chyba, tedy taková, která umožňuje například okamžitý únik citlivých údajů či převzetí administrace portálu, byla v případě analýzy jedné testovací firmy identifikována celkem u 42 procent projektů testů webových aplikací. Chyba s klasifikovanou „vysokou“ závažností (například neperzistentní cross-site scripting umožňující krádež přihlašovacích údajů za předpokladu, že uživatel klikne na podstrčený odkaz) byla zjištěna dokonce u 88 procent projektů.

Významnou a možná i klíčovou příčinou všech těchto nelichotivých čísel a především nepříjemných událostí je nedostatečné zapojení bezpečnosti do vývoje a do celého životního cyklu webových aplikací. Nezřídka se stává, že se k penetračnímu testování dostane webová aplikace, která už je i několik let v provozu, ale přesto u ní zatím prakticky vůbec nebyla řešena bezpečnost. Výsledky těchto aplikací ohledně stupně ochrany bývají velice nelichotivé.

Za výrazný pokrok (a dnes už jde o nejobvyklejší přístup u větších organizací) lze považovat provedení penetračních testů před zahájením ostrého provozu aplikace. To samozřejmě bezpečnosti aplikace výrazně pomůže, je to však obvykle spjato s celou řadou problémů.

Často se totiž stává, že v aplikaci jsou nalezeny závažné bezpečnostní chyby, které je poměrně náročné opravit. To s sebou přináší odložení ostrého provozu aplikace a prodražení vývoje. Zvláště nepříjemná je taková situace u aplikací, které jsou dodávány externí vývojářskou společností – velice často je nutné za práce, které spočívají v opravení identifikovaných chyb, zaplatit další nemalé peníze.

V některých případech, zejména pokud má nalezená chyba souvislost s obchodní logikou aplikace, by byla oprava natolik náročná, že se finančně nevyplatí, a je proto přijatelnější přijmout riziko plynoucí z možného zneužití této chyby. Avšak kdyby dané riziko bylo identifikováno ještě před zahájením vývoje aplikace, tato chyba se v aplikaci nemusela vůbec objevit, a software tak mohl být levný i bezpečný zároveň.

Samy penetrační testy také zdaleka nejsou všemocné – odhalí pouze tolik chyb, kolik jich je schopný najít příslušný testerský tým. Vyhodnoceny jsou obvykle jeden nebo jen několik vektorů útoku – aplikace je kupříkladu testována pouze z pohledu běžného uživatele přistupujícího přes internet, ale již ne z pohledu správce aplikace či jiných uživatelských rolí. Přitom statistiky ukazují, že stále větší množství útoků (nejen na webové aplikace) je vedeno zevnitř společnosti.

Penetrační testy rovněž nebývají prováděny po každé změně v aplikaci, takže se zhodnotí pouze její jeden konkrétní stav, ale nikoliv již její další rozvoj, při kterém samozřejmě může dojít a také dochází k zavedení dalších bezpečnostních slabin.

Proaktivní přístup
Větší organizace si tento problém začínají uvědomovat a snaží se více zapojit otázku zabezpečení už do fází předcházejících bezpečnostním testům. I ta ovšem bývá ve velkém množství případů uchopena velice nedůsledně a ochrana je v tomto případě definována pouze velmi vágně. Bezpečnostní požadavky na aplikaci bývají například často stanoveny tak, že software nesmí být náchylný na zranitelnosti v rámci seznamu OWASP Top Ten (projekt vyhodnocující deset nejčastěji nacházených zranitelností u webových aplikací).

V rámci tohoto přístupu pak dochází k poměrně nešťastnému uchopení projektu, kdy nejčastěji objevované chyby (jde o čistě statistické údaje) bývají zaměňovány za nějaký kompletní výčet. Je pochopitelně velkým omylem namlouvat si, že pokud bude aplikace odolná vůči těmto deseti chybám, tak bude bezpečná vůči útočníkům všeobecně.

Řešení, které je potřeba přijmout, musí být mnohem systematičtější a jeho cestu naznačují kroky softwarových gigantů (například v případě Microsoftu jde o aktivitu security development lifecycle) či poskytovatelů kritických bankovních aplikací. Základní filozofií jsou v tomto případě identifikace a mitigace rizik již od počátku definice funkcionalit aplikace a následné udržování, případně rozvíjení bezpečnostní úrovně po celou dobu životního cyklu aplikace.

Nejdříve je nutné aplikaci na základě skutečného rizika klasifikovat – tedy ujasnit si, s jak citlivými daty bude pracovat, jaké funkcionality bude poskytovat, v jakém prostředí bude provozována a jak kritická je pro svého provozovatele. V případě, že daná společnost poskytuje větší množství aplikací, ukazuje se jako finančně efektivní zřízení určitého počtu kategorií (například tři), do kterých budou poskytované aplikace rozřazeny a následně budou z dané kategorie dědit bezpečnostní požadavky a základní opatření.

Následně jsou definována konkrétní bezpečnostní opatření, a to v technické, procesní a organizační rovině. Zejména posledně jmenovaná jsou značně podceňována – typickým příkladem je nepřipravenost společností na útoky, nedostatečná analýza událostí, které se dějí v aplikaci (a s jejichž znalostí by bylo možné velice často zabránit úspěšnému dokončení útoku), absence komplexního bezpečnostního plánu aplikace a podobně. Opatření by měla být vybírána s pomocí již prověřených bezpečnostních norem (například NIST), aby bylo možné předejít vzniku nepokrytých oblastí ochrany.

Poté přichází na řadu implementace daných opatření a samozřejmě jejich ověření. Zde se pak obvykle nejedná pouze o penetrační testy, ale také o technické či procesní audity. Jen tak je možné prověřit bezpečnost aplikace ze všech zásadních úhlů pohledu a zhodnotit, zda jsou opatření implementována komplexně a v dostatečné kvalitě. Pokud aplikace projde těmito audity, je možné ji nasadit do ostrého provozu.

Nekončící proces
I ve fázi provozu hraje ověřování bezpečnosti významnou roli. Je důležité vyhodnocovat nejen události, které se dějí v samotné aplikaci (například pokud probíhá nový útok, je nanejvýš vhodné jej zavčas rozpoznat a útočníkovi v prolomení aplikace pokud možno zabránit), ale i události, které se dějí mimo aplikaci.

Lze například proaktivně využít znalostí o útocích, kterým jsou vystaveny obdobné aplikace (například různé phishingové vlny), ale například i nově objevovaná zranitelná místa (příkladem může být zranitelnost v SSL protokolu zjištěná koncem minulého roku, která umožňuje útoky typu man-in-the-middle, a na niž je nutné reagovat změnou konfigurace SSL).
Dále je vhodné bedlivě sledovat rozvoj aplikace – většina aplikací se samozřejmě průběžně rozvíjí a poskytuje nové funkcionality, které mívají zásadní vliv na celkovou úroveň bezpečnosti. I to je jeden z důvodů, proč je schéma na obrázku organizováno do nekonečného cyklu.

Finanční paradox?
Praxe ukazuje, že pokud je zabezpečení aplikace pojato zodpovědně a komplexně již od začátku jejího vývoje, má to příznivý vliv nejen na samotnou bezpečnost, ale trochu překvapivě i na celkové náklady s vývojem a provozem aplikace spojené. Kupříkladu podle společnosti Gartner zlevní identifikace pouhé poloviny rizik v analytické fázi vývoje provoz aplikace o celých 75 procent.

Jiné statistiky ukazují, o kolik levnější je předcházet bezpečnostním chybám proaktivně – z výzkumu společnosti Fortify vyplývá, že pokud je společnost bezpečnostní slabinu schopna vyřešit ve fázi analýzy, je to v průměru stokrát levnější, než pokud je potřeba následně upravovat již hotový kód.

Pohled na tato čísla říká, že když firma na začátku více investuje, na konci ušetří. K tomuto závěru došla ve zveřejněné studii i firma Microsoft, která porovnala náklady na opravu bezpečnostních chyb před implementací svého již výše zmíněného programu security development lifecycle (SDL) a po ní. Ačkoli se bezpečnostních chyb pravděpodobně nelze nikdy definitivně zbavit, zveřejněné závěry hovoří zcela jednoznačně o výhodnosti implementace SDL. A jelikož osvědčené zásadní kroky obvykle dědí od větších společností rovněž ty menší, objevují se už i na českém trhu firmy, které na podobných projektech pracují. Domnívám se, že tento přístup posune aplikační vývoj o celou jednu generaci vpřed.

Autor pracuje jako IT Security Consultant ve společnosti AEC.