Existuje 100 % bezchybný software? Existuje 100 % bezpečný software? Odpověď na obě otázky zní NE, ale nepropadejte panice. Vysokým procentům se lze totiž přiblížit, pokud budete myslet na bezpečnost již ve fázi přípravy architektury a návrhu budoucího systému a dále promítat security perspektivu i do průběhu vývoje.
Tyto otázky si položila např. menší firma zabývající se finančními transakcemi. Uvedená firma poptala firmu Citadelo na provedení Penetračního testu, který odhalil kritické zranitelnosti. „Ačkoliv je sice implementovaný mechanismus pro validování vstupů od uživatelů, naneštěstí není aplikovaný plošně a najdou se místa, kde vývojář pozapomněl validaci nastavit. Pro hackera toto představuje tzv. vstupní bránu. Doporučujeme proto při vývoji použít již existující validační framework.”, říká penetrační tester.
Zákazník byl z kritických nálezů zděšený, avšak po konzultaci penetračních testerů s vývojáři a opravení chyb byl zákazník s výsledkem spokojený a tak spolupráce pokračovala nejen v dalších kolech penetračních testů ale i do oblasti kryptografie.
Z čeho se Penetračný test podle žebříčku OWASP TOP 2017 skládá: A1 - Injection A2 - Broken Authentication A3 - Sensitive Data Exposure A4 - XML External Entities (XXE) A5 - Broken Access Control A6 - Security Misconfiguration A7 - Cross-Site Scripting (XSS) A8 - Insecure Deserialization A9 - Using Components with Known Vulnerabilities A10 - Insufficient Logging & Monitoring
Jak tedy aplikovat opatření v průběhu návrhu a vývoje webových aplikací:
1) PŘÍPRAVA
S čím začít? Při výběru technologie zohledněte známé zranitelnosti (CVE) a vyberte verzi technologie, která představuje minimální riziko (dle četnosti a kritičnosti CVEs) - pokud můžete, vyhněte se zastaralým, “děravým” či nepodporovaným řešením
Vymýšlet kolo? Ne nutně. Zapojte hotové a osvědčené frameworky = např. vhodný webový framework dokáže odchytit pokusy o Injections - Hibernate, Spring framework, Angular security
Hodí se dobrý návrh? Rozhodně. Klasifikujte dobře citlivost dat a navrhněte jejich adekvátní zabezpečení přes oprávnění. Myslete na role již od začátku vývoje.
Kdo ví, umí. Zajistěte svým vývojářům proškolení v oblasti bezpečnosti a bezpečného vývoje, který jsme v Citadelo realizovali pro již několik Development oddělení.
2) V PRŮBĚHU VÝVOJE
Kontrola/Dohled shora? Osvědčeným mechanismem kontroly kvality vyvíjeného řešení a minimalizace chyb způsobených juniorními vývojáři je provádění pravidelných code review a stanovení zodpovědného Architekta, který bude validovat veškeré nové přírůstky v repository (Gitlab, SVN) - takto odhalíte slabiny na počátku i v průběhu vývoje.
Nevěřte nikomu. Data: Velkým omylem bývá důvěra, že validaci vstupních dat provedl ten, kdo data poskytuje. Programujte validaci předávaných dat mezi komponentami formou nedůvěry - tj. např. při komunikaci klienta s back-end (Rest API, Webovými Službami, apod.) nespoléhejte pouze na validaci na straně klienta, ale validujte vždy vstupy i výstupy na potenciálně nebezpečné znaky na straně serveru/back-end (převedení znaků na HTML entity, whitelist povolených znaků, sanitizace = filtrování). Oprávnění: Ověřujte platnost session/tokenu uživatele při každé akci uživatele. Nezapomeňte vždy validovat oprávnění na každou operaci. Komunikace: Whitelistujte raději než Blacklistujte. Např. explicitně povolené cíle, se kterými aplikace smí komunikovat jsou preferovanou variantou oproti vybraným zakázaným, která nepokryje vše. Kontrola: Při načítání souborů minimalizujte možnost ovlivnění cesty k souborům uživatelem. Vyvarujte se načítání cesty k souborům jako parametru. Při nedostatečné validaci by uživatel mohl načíst soubor z disku serveru. Také nedoporučujeme benevolenci při nahrávání souborů, striktně kontrolujte povolené typy souborů (i na straně back-endu) a jejich obsah.
Stanovte jasné bezpečnostní politiky - auth level, password policy, princip ochrany proti opakování requestů (princip unikátních tokenů), ochrana proti bruteforce (captcha).
Pohlídejte si doporučované bezpečnostní hlavičky. V odpovědích ze serveru by neměly chybět minimálně HSTS, X-Frame-Options, a dále také atributy klíčových cookies jako HttpOnly a Secure.
Šifrujte kde to jde - v db, po cestě (všude https).
Může nastat v aplikaci chyba? Ano, ale pohlídejte si všechny error stavy pomocí implementace custom error stránek.
Nebojte se používat anti-CSRF tokeny, nebo případně JWT Session token, který bude uložen v Local storage na straně klienta.
Nezapomeňte na konfiguraci. Vypněte co není bezprostředně nutné = nepotřebné demo/konfigurační stránky (nepotřebné features, komponenty, dokumentace a ukázky), změňte výchozí url admin rozhraní + výchozí přihlašovací údaje; vypněte debug mode. Nastavení XML parseru je důležité, aby nepodporovalo načítání externích entit, což by mohlo umožnit útok XXE (XML External entity). Tento útok může vést k odhalení důvěrných dat, vyřazení služby, podvrhnutí požadavků na straně serveru, skenování portů a souborů z pohledu počítače, kde XML parser běží.
Nevystavujte zbytečně citlivé informace. Pro testovací/produkční release se vyhněte citlivým informacím v komentářích v kódu, NIKDY nezapisujte přihlašovací údaje do komentářů, nebo napevno do kódu.
Pozor na Business logic. Pohlídejte si, aby uživatel nemohl některý krok přeskočit/obejít, obejít validaci na klientu (např. upravit výslednou cenu přímo v requestu…). Takto se občas daří pojistit se na 999999999Kč nebo nakoupit bez nutnosti registrace za -50000Kč.
3) ČÍM NAVÁZAT?
Různá prostředí? Ano, využívejte prostředí na DEV,TEST,PROD, avšak snažte se zachovat identickou konfiguraci.
Záplatujte/záplatujte/záplatujte - z pohledu vývoje to znamená = aktualizujte verze použitých knihoven.
Součástí testovací fáze nového release aplikace by měl být penetrační test.
Závěrem: Co poradit naší firmě do budoucích projektů? “Vývojářské týmy většinou řeší priority, které bývají mylně stanoveny jako datum dodávky a kritérium financí.”, konstatují s povzdechem IT zaměstnanci, zodpovědní za IT bezpečnost firmy. Sami si totiž moc dobře uvědomují, že nápravy, které později vyplývají z úniku dat, nebo v lepším případě z nálezů z Penetračního testu, bývají o mnoho náročnější, než zapojení konceptu bezpečnosti již do návrhu a průběhu vývoje webových aplikací.
