Popravdě řečeno, co by se mělo testovat jiného než to, zda aplikace dělá to, co má, a jestli zvládne zátěž tolika uživatelů, pro kolik je plánována? Na co se ale zatím trochu zapomíná, je ověření bezpečnostních kvalit dodávané aplikace.
Přitom při dnešním trendu, kdy je většina aplikací realizována pro tenkého klienta, jenž je často navíc otevřený do internetu, je bezpečnost velmi důležitým kvalitativním parametrem. Co může slabé zabezpečení aplikací organizaci způsobit, by mohlo být tématem jiného článku – ale zřejmě každý se již doslechl o případech odcizených čísel kreditních karet nebo vykradeném elektronickém bankovnictví.
Bezpečnost je v současnosti ve většině firem vnímána spíše jako záležitost IT infrastruktury – počínaje firewallem a konče antivirem na pracovní stanici. To, že některé firemní aplikace představují pro zkušeného hackera „zadní vrátka", díky kterým se vyhne všem důmyslným kontrolám u vstupní brány, je často v pozadí zájmu jak managementu, tak i příslušných IT specialistů.
Pokud už ale bezpečnostní testy aplikace jsou součástí akceptačního řízení, omezují se obvykle na některý z těchto scénářů:
• Bezpečnostní test se omezuje na kontrolu správného nastavení přístupových oprávnění pro jednotlivé role, respektive typy uživatelů, a na revizi správného auditního logování.
• Méně často přichází na řadu ještě „hacker", který podle svého nejlepšího vědomí
a svědomí otestuje, zda je aplikace odolná proti známým typům útoků.
Oba výše zmíněné přístupy však mají své omezení. V prvním případě se pouze ověřuje, zda autorizovaný uživatel může dělat jen to, co mu bylo opravdu povoleno, ale neřeší se například možné odcizení identity (tedy to, že se za autorizovaného uživatele vydává úplně cizí osoba). V druhém případě je nutné se spoléhat na kvality bezpečnostních specialistů – jednak z pohledu profesního (že se ve svém oboru dobře orientují, že si pravidelně doplňují znalosti o hrozbách v aktuálně používaných technologiích a podobně ), a jednak z pohledu procesního (kvalitní metodika testu, prokazatelnost, opakovatelnost testu apod.).
Automatizace testu
Řada firem již dokáže ocenit přínosy nástrojů pro podporu softwarového vývoje. Přínosy jsou zvlášť zřetelné v oblasti Quality Assurance, resp. testování jako takového. Zátěžový test si bez podpory příslušného nástroje už dnes skoro nelze ani představit. Málokdo dokáže zorganizovat desítky či stovky testerů, kteří by reprezentovali dostatečně velký vzorek současně pracujících uživatelů, dát jim potřebné zdroje a hlavně to všechno zaplatit. U funkčních testů lze použitím vhodného nástroje také dosáhnout značných úspor, zejména pokud je nutné testovací scénáře často opakovat a mezi jednotlivými verzemi se aplikace příliš nemění.
Podobně tomu může být i u bezpečnostního testu, pro který lze využít automatizovaný skener. Nástroj se chová podobně jako robot pro funkční test, to znamená, že vyhledává v aplikaci konkrétní okna a pole, vkládá do nich určité hodnoty a sleduje, jak se při těchto podnětech aplikace chová, jaké vrací výstupy a případně co odesílá na server.
Rozdíl spočívá zejména v tom, že nejsou používána běžná testovací data, ale speciální řetězce, které mohou zneužít bezpečnostní díry v aplikaci. Tyto řetězce nástroj načítá z interní databáze hrozeb, vkládá je do různých polí v aplikaci a podle reakcí aplikace sleduje, zda je proti jednotlivým pokusům o průnik dostatečně odolná, či nikoliv.
Výstupy se liší podle použitého nástroje. Některé umí uživatelům poskytnout srozumitelný report s rozpisem nalezených problémů a návody k jejich odstranění, u jiných je výstupem technický výpis provedených testů a jejich výsledků ve formě příslušného logu. V takovém případě ale musí být log předmětem další analýzy, kdy je ohodnocena závažnost každého incidentu a také jsou navržena případná nápravná opatření. Výstupy by ale měly být v každém případě zrevidovány osobou znalou problematiky, protože některé nalezené nedostatky nemusejí být právě pro zkoumanou aplikaci příliš relevantní. I tak nástroj představuje významnou úsporu zejména v tom, že dokáže aplikaci otestovat rychle, opakovatelně a s využitím aktuálních informací o bezpečnostních hrozbách.
Testování vs. penetrační testy
Bezpečnostní testování je v mnoha aspektech proces podobný penetračním testům. Na rozdíl od něj se však zaměřuje zejména na bezpečnostní mezery samotné aplikace, zatímco penetrační test reviduje i úroveň infrastrukturní bezpečnosti. Penetrační test je také obvykle prováděn nezávislou autoritou, která není zainteresována na vývoji a dodávce samotné aplikace.
Bezpečnostní testování tedy v žádném případě nemůže nahradit penetrační testy, ale jeho zavedení do životního cyklu vývoje softwaru má řadu pozitiv. Mezi ty hlavní patří eliminace nedostatků ještě během vývoje, tedy dříve, než mohou být zneužity v produkčním prostředí – stejně jako u jiných typů chyb platí, že čím dříve se je podaří odhalit, tím jsou náklady na opravu nižší. Není totiž nic náročnějšího než opravovat chybu v aplikaci, která je v plném provozu.
Řada bezpečnostních mezer je navíc záležitostí architektury celého systému, kterou už není možné v produkčním provozu měnit vůbec, a chyby je tak nutno nouzově záplatovat. Jedinou prevencí budoucích problémů tedy je průběžné testování výstupů od architektonického prototypu až po finální verzi produktu.
Nic to ovšem nemění na tom, že „automatizované hackery" je možné s úspěchem využít i při penetračních testech, zejména díky jejich širokému záběru, automatizaci a rychlosti, se kterou mohou celou sadu testů realizovat.
Autor pracuje ve společnosti Unicorn jako produktový manažer.