Vývoj software: jaké jsou základní bezpečnostní principy?
O tom, že kvalitní zabezpečení softwaru je důležité, nikdo nepochybuje. V praxi se ovšem stává, že se bezpečnostní otázky řeší až pět minut po dvanácté a oprava chyby v softwaru stojí více úsilí, než je nutné. Vyplatí se proto nastavit si bezpečnostní požadavky hned v začátcích celého projektu a důsledně je dodržovat. Náklady na vývoj budou sice o něco vyšší, ale v konečném součtu mohou ušetřit nejen prostředky za dodatečné opravy, ale i pověst firmy.
- 05. 03. 2020
- 9 min čtení
Tlak na rychlost a cenu, málo času nebo nedostatečné kapacity. To jsou hlavní důvody nedodržení bezpečnostních zásad vývoje softwaru. Přitom problémy s únikem citlivých dat nejenže poškozují dobré jméno firmy, ale mohou znamenat i milionové pokuty za porušení zákona.
Co se může stát při zanedbání standardních postupů při vývoji softwaru, ukázal lednový projekt Znamkamarada, jehož cílem bylo během víkendového hackathonu vytvořit komplexní informační systém na dálniční známky včetně e-shopu. Právě ten se stal Achillovou patou celého softwarového řešení, jelikož hned první den došlo k úniku stovek osobních údajů. Iniciátoři hackathonu o několik hodin později problém přiznali a jako důvod uvedli podcenění penetračního testování kvůli časovému presu.
Nedostatečné zabezpečení ale není jen problém projektů s šibeničním termínem. Tento nešvar je bohužel častý i při běžném postupu. Rozhodli jsme se proto shrnout základní zásady, které by se při vývoji softwaru měly dodržovat.
Respektované metodiky bezpečného vývoje softwaru
Nejrůznějších příruček, jak psát správně zabezpečený software, existuje více a některé z nich jsou skutečně podrobné a rozsáhlé. Jako příklad uveďme metodiku od Microsoftu nebo od OWASP, uznávané organizace, která se zabývá bezpečností softwarového vývoje.
Základním pravidlem je myslet na bezpečnost softwaru ve všech jeho vývojových fázích – tedy od obecného návrhu až po produkci a pravidelnou údržbu. Obecně také platí, že čím dříve se potencionální hrozby odhalí, tím je levnější a rychlejší je odstranit. Naopak ve chvíli, kdy se v raných stádiích vývoje něco zanedbá, prostupuje chyba celým projektem a v konečné fázi je její případné odstranění časově mnohem náročnější.
Software na zakázku
Potřebujete vytvořit webovou nebo mobilní aplikaci? Napište si o nezávaznou schůzku, kde s vámi vše probereme a připravíme základní kalkulaci ceny.
1. Fáze: Analýza požadavků
Stanovení uživatelských požadavků je základním stavebním kamenem softwarového projektu. V úvodní fázi se vytváří obecné cíle a funkcionality, a právě to je ten pravý čas určit odborníka, případně tým odborníků, který bude po zbytek projektu dohlížet na dodržování bezpečnostních standardů a eliminaci rizik.
Jedním z prvních kroků takového experta nebo týmu je určení minimálních požadavků na bezpečnost a identifikace částí projektů, které budou vyžadovat obzvlášť důkladnou kontrolu.
Nezbytné je také nastavení kontrolních mechanismů v průběhu vývoje softwaru. Určit by se mělo, co, kdy a jakým způsobem se bude měřit, aby byl výstup v souladu s bezpečnostními požadavky. Jedním z kontrolních mechanismů je Go/no-go testování, tedy ověření, že dílčí část kódu nebo určitá funkcionalita běží tak, jak bylo zamýšleno.
Samozřejmě se stává, že v průběhu vytváření softwaru dojde k podstatným změnám některých funkcí nebo třeba způsobu implementace. V takových případech je nutné pružně reagovat a podle potřeby měnit i nastavené mechanismy a metriky tak, aby byla požadovaná kvalita výsledného kódu zachována.
Dalším krokem je analýza konkrétních případů zneužití ze strany uživatelů. Typickým příkladem je pokus o obejití registrace nebo přístup do aplikace bez přihlášení. Monitorováním a analýzou takových pokusů je možné podobným situacím předejít.
2. Fáze: Návrh (design) softwaru
Při návrhu designu softwarového projektu se podrobně rozepisují jednotlivé funkce a operace, řeší se uživatelské rozhraní, obchodní podmínky, procesy a další dokumentace. Výsledkem je soubor modulů a subsystémů, které budou dohromady tvořit výsledný software.
Tato fáze je současně nejvhodnějším okamžikem k upřesnění obecných bezpečnostních požadavků. Je-li například vyžadováno, aby byl ovládací panel přístupný jen registrovanému uživateli, ujasněte, jestli se jedná o pouhou registraci do systému, nebo musí dojít i k autorizaci.
Správa uživatelů, se kterou je úzce spojena ochrana osobních dat a přístup do různých částí systému, je rovněž důležitou položkou na pomyslném chcecklistu vývoje. Specifické akce v rámci softwaru, jako je třeba administrace účtů nebo upravování určitých vlastností, by měly být povolené jen uživatelům s vyšším stupněm oprávnění.
„Pokud se zaměstnanci musejí vzájemně zastoupit, ať přistupují do databáze pod vlastními jmény a mají na svých účtech přizpůsobená oprávnění. Sdílení hesel představuje bezpečnostní riziko. Přístup uživatelů musí být auditovatelný, tzn. přesně vědět kdo, co a kdy změnil.” zdůraznil na jednom z eventů u Mastera Radovan Vacek, ředitel společnosti Insighti, jež se zabývá ochranou dat.
Vytvořte si dokumentaci celého projektu. Zařaďte do ní modely, textové dokumenty a všechny prvky, u nichž je potřeba otestovat, zda navrhovaná architektura a design softwaru dokáží zajistit jejich stanovenou úroveň zabezpečení.
Během navrhování systému získáváte prostor nejefektivněji identifikovat nedostatky. Nezabere to totiž tolik času jako v pozdějších stádiích. Jestliže víte o nějaké funkci, kterou by měl systém umět, vybavte ho potřebnými prvky pro tuto funkci. Chcete například autorizovat na několika místech? Už teď zvažte přidání autorizační komponenty.
Stěžejní součástí designové fáze jsou i UML (Unified modeling language) diagramy, které slouží k standardizované vizualizaci návrhu systému, jeho prvků a procesů. Z bezpečnostního hlediska by se do UML diagramu měly zakreslit možné hrozby a zneužití.
Příklad UML diagramu se zakreslenými riziky. Zdroj: Researchgate.net
Některá bezpečnostní opatření mohou selhat. Počítejte s takovými případy a zařaďte do návrhu několik bezpečnostních vrstev, a to zejména na ochranu nejcitlivějších částí projektu. Použijte třeba tzv. hashování hesel (skrze algoritmy Bcrypt a Argon2id), případně dalších dat. Pokud se hacker dostane k zahashovaným údajům, nebude schopen je přečíst.
Návrh by měl navíc obsahovat i opatření pro případ, že software přestane z nejrůznějších důvodů fungovat úplně. Myslet by se mělo zejména na to, aby po dobu selhání byly zakázány všechny přístupy, zrušily se nežádoucí změny v konfiguracích a software bylo možné obnovit do zabezpečeného stavu.
3. Fáze: Vývoj softwaru
V ideálním světě by fáze vývoje zahrnovala jen překlopení návrhu do funkčního kódu. V praxi se ale spousta důležitých rozhodnutí udělá až při samotném programování. Pokud se jedná o změny, pro něž v předchozích dvou fázích nebyly zvolené požadované standardy a postupy, měly by se dodatečně vytvořit.
Poměrně komplexní kontrolní seznam požadavků na bezpečné kódování vydala OWASP, která také zveřejňuje seznam deseti nejzávažnějších rizik pro webové aplikace a každé 3 až 4 roky ho aktualizuje.
TOP 10 rizik podle OWASP (2017)
1. Vsunutí škodlivého kódu (injection) – Součástí odeslaného příkazu jsou nedůvěryhodná data, která spouští nechtěné nebo neoprávněné funkce.
2. Prolomení autentizace – Nedostatečné ověřování relací může vést k úniku přihlašovacích údajů nebo umožňuje útočníkům předstírat identitu skutečných uživatelů.
3. Nechtěné zpřístupnění citlivých dat – Webové aplikace nebo API nemají dostatečně zabezpečená důvěrná data a hackeři tak mohou získat čísla kreditních karet nebo osobní údaje.
4. Externí entity v XML – Využívání externích entit v XML je nevhodné, protože je hackeři mohou zneužít ke spuštění škodlivého kódu, k DDoS útokům nebo přístupu k souborům.
5. Nedostatečná kontrola přístupu – Pokud nejsou úrovně přístupu dostatečně chráněny a kontrolovány, uživatel s nižším přístupem může zneužít svá oprávnění a získat data nebo přístup ke chráněným funkcím softwaru.
6. Chybné konfigurace – Patří mezi ně neúplná konfigurace zabezpečení, špatné HTML záhlaví, příliš otevřené cloudové úložiště nebo chybové zprávy obsahující detailní či citlivé informace.
7. Skriptování napříč webem (XSS) – Při chybě v XSS může útočník spouštět v prohlížeči oběti škodlivé skripty, které ho například přesměrovávají na nebezpečné weby nebo zpomalují uživatelské relace.
8. Nezabezpečená deserializace – Deserializace je převádění sériově upravených objektů do původní podoby. V případě, že je chybně zabezpečená, může vést k řadě útoků.
9. Známé zranitelnosti třetích stran – Jsou-li v kódu komponenty třetích stran, otevírá se útočníkům další možnost zneužití, jako je ztráta dat nebo dokonce převzetí serveru, a to obzvlášť pokud jsou použity neaktualizované verze těchto komponent.
10. Nedostatečné protokolování a monitorování – Pozdní odhalení útoků a různých typů zneužití dává hackerům čas navíc, díky čemuž mohou napáchat mnohem větší škody.
Bezpečnostní tým pak s vývojáři a případně i s architekty systému podrobně prochází výsledný kód, aby vývojáři vysvětlili zvolená řešení a celkovou logiku kódu. Díky tomu bezpečnostní tým lépe pochopí celou strukturu, rozložení a funkčnost vytvořeného softwaru. Také pro tuto část vývoje nabízí OWASP rozsáhlou metodiku jak postupovat.
4. Fáze: Testování
Při testování softwaru se zjišťuje nejen zda software funguje tak, jak bylo zamýšleno, ale provádí se i tzv. penetrační testy, které simulují možné útoky a zneužití softwaru zvenčí i zevnitř. Je velmi důležité, aby se penetrační testování spustilo ve všech možných nastaveních a konfiguracích vyvíjeného softwaru.
Obzvlášť pro robustnější softwarové projekty je vhodné vytvořit automatické penetrační testy, případně použít některé nástroje a skenery na bezpečnostní testování, jako například Netsparker, Acunetix nebo OWASP ZAP.
Výsledek penetračních testů ukáže, nakolik byla práce vývojářů a bezpečnostního týmu v předchozích fázích úspěšná, a kterým částem projektu je ještě nutné věnovat pozornost. Jedná se v podstatě o závěrečnou kontrolu, která otestuje, zda se na nic nezapomnělo a zase se podařilo dodržet stanovené bezpečnostní požadavky.
Velkou výhodou je, pokud testeři ovládají i kódování. „Jejich spolupráce s vývojáři je pak o poznání jednodušší, na případné problémy se přijde téměř okamžitě už během vývoje, řadu prvků je i mnohem snadnější implementovat. Testeři jsou si totiž dost často vědomi různých zákoutí, protože znají aplikaci z trochu větší dálky a jiné perspektivy než vývojáři,” vysvětlil na panelové Diskuzi u Mastera Michal Špaček, webový vývojář a odborník na bezpečnost.
5. Fáze: Nasazování a údržba
Při nasazování softwaru se provádějí další penetrační testy, které ověří, jestli zabezpečení funguje i v nasazovaném prostředí, a znovu zkontrolují, zdali software splňuje všechny bezpečnostní požadavky stanovené v počátečních stádiích projektu.
Ani úspěšným nasazením však práce bezpečnostního týmu nebo experta nekončí. Přichází čas na vytvoření plánu reakce na případné bezpečností selhání. Plán obsahuje vhodný postup a kontakty osob kvalifikovaných k řešení takových situací. Pokud software využívá řešení třetích stran, nezapomeňte, že i ta mohou obsahovat jistá bezpečnostní rizika.
Úplně nakonec naplánujte pravidelné bezpečnostní audity. Příkladem mohou být každoroční penetrační testy na částech softwaru, které jsou nejvíce náchylné ke zneužití. Jakékoli budoucí změny v softwaru pak procházejte dalším testováním, aby vše bylo v souladu s bezpečnostními požadavky.
Kvůli stále novým způsobům, kterými se hackeři dokážou nabourat do softwaru, jsou budoucí updaty nezbytné a nasazením softwaru do finálního prostředí práce developerského týmu nekončí. Právě to, jak se firma stará o bezpečnost svého softwaru, je její viditelnou vizitkou, ať už v pozitivním nebo negativním slova smyslu.
