Open Web Application Security Project osobně

V OWASP se snažíme o to, aby svět byl místem, kde riskantní software je anomálií, ne normou. Chceme, aby softwarová bezpečnost byla viditelná tak, aby jednotlivci a organizace mohli přijmout informovaná rozhodnutí o rizicích a zabezpečení.

Jednotlivé OWASP projekty, jichž je opravdu mnoho, vytváří kousky skládačky aplikační bezpečnosti. Tím také nabízí zcela zdarma know-how bezpečnosti webových aplikací, které je skvělým startem k budování a udržování bezpečných aplikací.

S OWASP se profesně setkávám již řadu let. Jedná se o neocenitelný projekt, který je schopen v oblasti bezpečnosti webových aplikací pomoci v nespočetných ohledech.

Jaká byla moje cesta k OWASP? Jakožto čerstvý tester v jedné nejmenované firmě jsem dostal za úkol provést retestování nálezů zjištěných externí společností. Firmě hrozily vysoké smluvní sankce od klienta, vyplývající z „nezabezpečené“ aplikace. Ve firmě si tehdy se zprávou nevěděl nikdo rady. Zpráva byla velmi obsáhlá a s bezpečnostním testováním do té doby neměl nikdo zkušenosti. Já také ne. Krátké googlování mě přivedlo k OWASP.

Rychle jsem se seznámil s OWASP Top 10 a pak mým hlavním pomocníkem byl OWASP Testing Guide – na dlouho se mi stal takovou malou „biblí“. Mantis (bug tracking system) se začal plnit nálezy. Ale ouha! Vývojáři si s nimi nevěděli rady. Někdy mi tikety vraceli s tím, že si nemyslí, že by se jednalo o „nějaké nebezpečí“. Jiní za mnou přicházeli s tím, abych jim nález vysvětlil, případně poradil, jak ho ošetřit. Programátoři, databázisté, projektoví manažeři, … Nálezy bylo zapotřebí ošetřit, ale bylo jisté, že stávající stav neznalostí lidí podílejících se na vývoji k výsledku nepovede. A tak s dalším zapáleným vývojářem jsme do problematiky začali zasvěcovat celou firmu – workshopy. Vedle OWASP Top 10, OWASP Testing Guide firma začala vstřebávat další OWASP projekty: OWASP Development Guide Project, OWASP .NET Project, OWASP Risk Rating Methodology. Aplikační bezpečnost se stala firemní samozřejmostí.

Později jsem pracoval pro různé společnosti, které OWASP adoptovali v různé míře. Ve většině z nich vznikl požadavek na zabezpečení aplikací především z jednoho z následujících pěti důvodů:

• hrozba sankce daná smlouvou
• hrozba nezískání potřebné licence pro provozování systému
• hrozba pozastavení či ztráta licence
• hrozba ztráty zakázky
• hrozba negativní medializace

Téměř u všech těchto společnosti k řešení otázek bezpečnosti docházelo buď téměř na konci vývoje (mnohdy až ve fázi akceptačního testování) anebo až po spuštění aplikace do ostrého provozu. Bohužel taková je velmi častá praxe. Byť je jasné, že by se téma bezpečnosti mělo objevovat v průběhu celého procesu vývoje a že je neefektivní nejdříve navrhnout a vyhotovit „děravou“ aplikaci a teprve až pak navrhnout a vyhotovit „neděravou“ aplikaci.

Přirozenou reakcí vývojářských společností na zmíněné hrozby je zjistit, jak vlastně na tom aplikace po bezpečností stránce je. Aplikace vám může otestovat specializovaná společnost anebo … když se vaši testeři naučí, jak bezpečnostně otestovat webovou aplikaci, jistě ušetříte nemalé peníze a možná získáte i konkurenční výhodu. Pokud testy provede jiná společnost, získáte, pokud dokážete dostatečně dobře zadat požadavky na otestování, sice někdy opravdu kvalitní výstupy, avšak vhodné interpretace nálezů a konkrétní způsoby ošetření jsou další věc. Pokud nemáte potřebné know-how, budete platit množství ne zrovna levných konzultací.

Nejednou jsem se setkal s případy, kdy si bezpečnostní manažer nechal provést bezpečnostní testy, avšak zprávu bez dalšího zájmu umístil v lepším případě do trezoru. Předpisy mu nepřikazovaly zprávou se dál zabývat, přikazovaly pouze provést bezpečnostní testování. Jindy bezpečnostní manažer zadával zakázku pro bezpečnostní otestování v takovém rozsahu a hloubce, aby testování odhalilo co nejméně slabin – svým nadřízeným následně prezentoval „úspěchy“ svého oddělení. Bohužel jsem se setkal i s takovým případem, kdy bezpečnostní manažer bez jakéhokoliv ostychu požadoval provést testy s takovým závěrem, které ochrání jeho nekalé činnosti. K problematice bezpečnostních manažerů, certifikacím, nezávislosti testování a auditů apod. se možná někdy vrátím, jen chci naznačit, že s aplikační (a nejen aplikační) bezpečnostní souvisí množství nejen morálních otazníků a vykřičníků, které nejsou příliš zmiňovány. A že i tester by měl vážit, kdy se do testování pustí či nikoliv, neboť takové testování může přinést více škod než užitku.

Ale zpět k OWASP. Co jsem během své praxe nejvíce oceňoval na OWASP?

• Kompletní a poměrně detailní návody, jak aplikace otestovat: OWASP Testing Guide
• Návody, jak vyvíjet bezpečné aplikace: OWASP Development Guide Project, OWASP .NET Project, OWASP Ruby on Rails Security Guide, OWASP Secure Coding Practises aj.
• Prioritizuje, na které slabiny se zaměřit: OWASP Top Ten, OWASP Risk Rating Metodology
• Užitečné nástroje pro testování: OWASP Zed Attack Proxy Project, OWASP Web Scarab Project, OWASP JBroFuzz Project
• Školící prostředky: OWASP WebGoat Project, množství různých připravených prezentací
• Obranné nástroje: OWASP ModSecurity Core Rule Set Project, OWASP AntiSamy Java Project, OWASP AntiSamy .NET Project
• Množství tematických e-mailových konferencí: oceníte, když si nebudete s něčím vědět rady

Nejednou mi pomohly i projekty, které hodnotím jako ne příliš zralé, např. OWASP Mobile Security Project, OWASP Education Project, OWASP Backend Security Project aj.

Ve světě vznikají lokální OWASP uskupení, které mají zájem na tom, aby svět Internetu byl bezpečnější. A jak jsem již v úvodu psal – aby svět byl místem, kde riskantní software je anomálií, ne normou a aby softwarová bezpečnost byla viditelná tak, aby jednotlivci a organizace mohli přijmout informovaná rozhodnutí o rizicích a zabezpečení. Přestože v Česku lze zaznamenat několik neúspěšných pokusů o vznik podobného lokálního OWASP uskupení, pevně věřím, že dříve nebo později se podaří i v Česku OWASP zastřešit dostatečně silnou autoritou.