Chcete sa vyhnúť zraniteľnostiam vo vami vyvíjanej aplikácii?

Ako sa zvykne hovoriť, dnes už nájdete aplikáciu naozaj na všetko. Či už píšeme dokument na počítači alebo pozeráme do obrazovky mobilu pri pozeraní videí. Každý takýto softvér musel niekto navrhnúť,  naprogramovať a takisto aj otestovať.

Na trhu je veľa rôzneho softvéru na tie isté činnosti a výrobcovia softvéru si svojimi produktami konkurujú. Predbiehajú sa v počte vlastností, funkcií a dizajne, ako aj v rýchlosti zavádzania noviniek. Produkcia softvéru je teda veľmi rýchla a dynamická. Takýto rýchly vývoj má však aj svoju tienistú stránku. Dizajnéri softvéru, ako aj programátori pracujú pod tlakom a robia chyby, prípadne si zjednodušujú prácu tým, že na niektoré oblasti nemyslia alebo si s nimi nedajú dostatočnú námahu. Takisto vyvíjaný softvér dostatočne neotestujú pred tým, ako ho uvedú na trh. Jednou z týchto zanedbávaných oblastí je samozrejme aj bezpečnosť.

Počet zraniteľností v programoch a aplikáciách neustále narastá, ako v malých aplikáciách na úrovni mobilných telefónov až po veľké softvérové riešenia vo veľkých organizáciách a verejných inštitúciách. Útočníci využívajú diery v softvéri vo svoj prospech a niekedy aj roky zostávajú tieto chyby neodhalené.

Existencia bezpečnostných dier v softvéri však nie je začarovaný kruh. Bezpečným programovaním sa počet kritických zraniteľností dá výrazne znížiť.

Preto vám Národné centrum kybernetickej bezpečnosti SK-CERT v rámci tzv. “programátorského týždňa” Európskeho mesiaca kybernetickej bezpečnosti prináša niekoľko základných pravidiel, ktoré vedú k bezpečnejšiemu produktu a mal by si ich osvojiť každý programátor.

Tento návod bol vo významnej miere inšpirovaný metodikou OWASP Secure Coding Practices, dostupnou na tejto adrese:

https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/migrated_content

Oblasť 1 – Dizajn

Bezpečnosť samozrejme začína už pri návrhu samotného softvéru, ktorý ideme programovať. Paralelne s návrhom funkcionality musíme dbať na nasledujúce parametre.

Pravidlo 1.1. – Bezpečnosť musí byť obsiahnutá už v návrhu aplikácie

Na začiatku celého dizajnovania je potrebné vykonať analýzu, ktorá zahŕňa všetky možné hrozby, ktoré môžu vplývať na výsledný produkt. Určenie všetkých vstupných bodov do aplikácie, definovanie útočných plôch (attack surface) a možných útočných vektorov je základ na identifikovanie možných zraniteľností a chýb, ktoré by mohli v procese samotného programovania nastať. 

Na modelovanie hrozieb je vhodné použiť napríklad STRIDE metodológiu. Tá definuje 6 základných hrozieb:

• Krádež identity používateľa (Spoofing of user’s identity)
• Manipulácia (Tampering)
• Odmietnutie (Repudiation (deniability))
• Vyzradenie informácií (Information disclosure)
• Nedostupnosť služby (Denial of service)
• Eskalácia privilégií (Elevation of privilege)

O metodológii STRIDE vám prinesieme samostatný článok už čoskoro!

V rámci základného bezpečnostného modelovania si je takisto potrebné uvedomiť bezpečnostné obmedzenia, teda akým spôsobom môžu opatrenia voči hrozbám ovplyvniť funkcionalitu softvéru.

Pravidlo 1.2. – Bezpečnosť musí byť základnou súčasťou softvérovej architektúry

Pri definovaní samotnej softvérovej architektúry treba dodržiavať niekoľko bezpečnostných odporúčaní.

V prvom rade je potrebné dostatočne rozdeliť povinnosti a to najmä modulárnou architektúrou, abstrahovaním rozhraní od algoritmov (definovaním API a ovládacích prvkov, ktoré API vynucujú), ako aj oddelenie frontendu, middleware a backendu.

Z bezpečnostného hľadiska je rizikové spoliehať sa na svoj vlastný kód, a to nielen pri rozsiahlych projektoch. Odporúčame používať framework s dobrou reputáciou, ktorý je udržiavaný a všeobecne používaný. Oprava prípadných zraniteľností v takomto frameworku je rýchlejšia, nakoľko je verejne auditovateľný komunitou, ktorej záleží na bezpečnosti. A hlavne, nie je to len Vaša zodpovednosť. V prípade databáz odporúčame používať ORM (Objected-relation mapping) a vyhnúť sa implementácii dynamických dotazov (queries).

V jednoduchosti je krása. A to platí aj pri programovaní. Čistý a čitateľný kód, používanie krátkych funkcií a opätovné používanie dôveryhodných komponentov dodajú vášmu programu prehľadnosť a umožnia jednoduchú orientáciu v ňom. Zložité programovanie je totiž viac náchylné na chyby.

Pri softvérovej architektúre takisto odporúčame, aby ste sa zamerali na používanie najlepších postupov a overenej praxe v oblasti tzv. “defense-in-depth” a používali viaceré vrstvy zabezpečenia.

Pravidlo 1.3. – Nezabúdajte na bezpečnú autentifikáciu

Prihlasovanie a rozoznávanie používateľov má v bezpečnosti svoje jasné pravidlá. V prvom rade riešte autentifikáciu mimo váš kód. 

V rámci prihlasovania dbajte na to, aby bolo umožnené, najlepšie vynútené, používateľom využívať metódy viacfaktorovej autentifikácie. 

Každému používateľovi je potrebné priradiť rolu, teda sadu oprávnení, ktoré mu umožňujú využívať funkcie vášho softvéru. Najlepšou cestou je vytvoriť väčšie množstvo rolí s minimálnym množstvom oprávnení, alebo umožniť prideliť každému používateľovi práva individuálne.

Aby ste sa vyhli tzv. brute force útokom, ktorých podstatou je neustále zadávanie hesla do momentu, kým nie je zadané správne, používajte mechanizmy, ktoré zabraňujú neustálemu zadávaniu hesiel viac krát po sebe.

Ak je súčasťou vášho softvéru aj komunikačná vrstva, opäť používajte známe a vyspelé protokoly, napríklad TLS. Vyhnete sa množstvu problémov so zaručením dôvernosti a integrity prenášaných dát a tiež sa vyhnete tzv. replay útokom, pri ktorých útočník zaznamená hoci aj zašifrovanú sieťovú komunikáciu a potom jej opätovným prehraním spôsobí rovnakú akciu, ako predtým zrealizoval autorizovaný používateľ.

Pravidlo 1.4. – Dbajte na šifrovanie

Pravidlo pravej ruky: šifrovanie či podpisovanie si NIKDY nevyvíjajte sami – drvivá väčšina programátorov totiž nedisponuje takými matematickými vedomosťami, aby vytvorila nový, unikátny a bezpečný šifrovací algoritmus.

Pri aplikácii kryptografických mechanizmov sa držte tzv. Kerckhoffsovho princípu – systém by mal byť bezpečný, aj keď je o ňom všetko verejne známe – či už ide o šifrovací algoritmus alebo spôsob kombinácie šifrovaného a nešifrovaného textu.

Použitie kryptografických mechanizmov je pre bezpečnosť doslova životne dôležité. Odporúčame však používať verejne známe kryptoknižnice, ktoré sú udržiavané a auditované na pravidelnej báze komunitou alebo ich tvorcom. Písať a udržiavať vlastný krytografický mechanizmus je časovo aj zdrojovo enormne náročné a je prakticky isté, že bude obsahovať bezpečnostné zraniteľnosti a slabiny. Bezpečnejšie je určite používať bežne dostupné algoritmy. Takisto nevytvárajte svoje vlastné kryptografické protokoly a použite radšej dobre známe kryptografické vzory. To isté sa kriticky týka aj generátorov náhodných čísel – na generovanie náhodných čísel nepoužívajte ani systémové generátory.

Ak si zvolíte určitý šifrovací algoritmus, programujte svoj produkt tak, aby bolo možné rýchlo a jednoducho takýto algoritmus a jeho parametre zmeniť. Každý kryptografický mechanizmus totiž môže byť napadnutý alebo obsahovať doposiaľ nezdokumentovanú zraniteľnosť a jeho výmena musí byť okamžitá, aby sa predišlo riziku zneužitia citlivých údajov. Dokumentácia použitých algoritmov a ich parametrov naprieč zdrojovým kódom je samozrejmosťou.

Pri práci s heslami takisto platí niekoľko základných pravidiel, zvyšujúcich bezpečnosť ich prenosu a ukladania. V prvom rade, heslá nesmú byť ukladané bez šifrovania alebo šifrované symetrickou šifrou. Vždy by mali byť  uchovávané iba v tvare hashu. Aby sa zabránilo útokom, ktoré využívajú predom vypočítané tabuľky hashov, hashe hesiel by mali byť ošetrené dlhým a pre každé heslo náhodne vybraným saltom. Pri šifrovaní používajte pomalé hashovacie mechanizmy, ako napríklad PBKDF2, bcrypt, scrypt s prihliadnutím na CPU-senzitívne mechanizmy, ktoré však môžu byť optimalizované cez GPU alebo ASIC. Už pri voľbe hesla zo strany používateľa dbajte na to, aby heslo spĺňalo všetky bezpečnostné náležitosti podľa moderných bezpečnostných odporúčaní (dĺžka – minimálny počet znakov, neobmedzovať maximálnu dĺžku, povoliť všetky možné znaky pri zadávaní, implementovať “merač” sily hesla, umožniť používanie fráz a pod.). Vynucovanie zmeny hesla pod používateľov v príliš častom intervale môže viesť k zníženiu bezpečnosti hesiel, najmä u používateľov, ktorí nepoužívajú aplikáciu na správu hesiel. Takisto používanie predvolených hesiel je potrebné zakázať, resp. vynucovať zmenu predvolených hesiel po prvom prihlásení a nastaviť aj vypršanie možnosti prvého prihlásenia s nutnosťou manuálneho administrátorského zásahu (obnova neaktívneho konta).

Pravidlo 1.5. – Segmentujte sieť a urobte bezpečný sieťový návrh

Moderné aplikácie sa často skladajú z viacerých komponentov (napríklad frontend, middleware, backend, databázy, vyhľadávacie servery, úložiská a ďalšie). Pri návrhu bezpečnej sieťovej architektúry sa zamyslite nad vhodnou topológiou, skladajúcou sa z viacerých striktne oddelených sieťových segmentov.

Segmentácia siete by mala byť taká, aby kompromitáciou jednej časti nebolo možné získať prístup k ostatným komponentom alebo odpočúvať dáta (napríklad iSCSI dáta iných serverov). Odporúčame oddeliť jednotlivé prvky stavovými firewallmi so striktne definovanou politikou (default drop) a ak je to možné, vykonávať inšpekciu obsahu. Manažmentové siete oddeľte od produkčných.

Pamätajte na to, že “perimeter je mŕtvy” – ochrana musí byť implementovaná v celej sieťovej topológii.

Ak sú súčasťou riešenia fyzické zariadenia, umožnite redundanciu a škálovateľnosť – na tieto vlastnosti je potrebné myslieť už pri návrhu softvéru. Sieťovú architektúru dimenzujte tak, aby DDoS na vstupné body neohrozil vnútornú komunikáciu a funkčnosť riešenia ako celku.

Pri sieťovom návrhu pamätajte aj na monitoring. Aplikácia môže poskytovať dáta pre nástroje na dohľad napríklad vo forme SNMP agenta.

Pravidlo 1.6. – Pri návrhu práce s dátami a úložiskom dbajte na bezpečnosť

K poškodeniu dát môže dôjsť z viacerých dôvodov. Napríklad chybou používateľa, v dôsledku útoku, alebo zlyhaním hardvéru.

Aplikácia musí korektne ošetrovať všetky možné chyby. Preto aj výpadok dát z databázy nemôže spôsobiť, že aplikácia vykoná neočakávanú funkciu, alebo sa používateľovi zobrazí chybové hlásenie, obsahujúce vnútorné implementačné detaily.

Softvér by tiež mal umožňovať zálohu a obnovu. Obzvlášť pri viac-serverových riešeniach je potrebné na to myslieť už pri návrhu softvéru, nakoľko čiastočná obnova môže viesť k nekonzistencii dát.

Ak sa poškodí fyzické médium a je ho potrebné zahodiť, môže sa stať, že sa na ňom stále nachádzajú obnoviteľné citlivé dáta. Jedným z opatrení, ktoré to uľahčia, je ukladanie dát v šifrovanej podobe.

Ak aplikácia ukladá citlivé dáta, pamätajte tiež na dodržanie požiadaviek platnej legislatívy a doplňte možnosť “zabudnutia”.

Pravidlo 1.7. – Vaša aplikácia musí generovať viacero druhov logov

Na logovanie využite vstavané možnosti zvolenej platformy alebo frameworku. Aplikácia by mala generovať niekoľko druhov logov:

• prevádzkové logy – informácie o bežnej činnosti aplikácie, ktoré nie sú potrebné pre koncového používateľa. Stačí ukladať lokálne do súborov. Nesmú obsahovať žiadne citlivé údaje, napríklad používateľské heslá.
• bezpečnostné logy – informácie o bezpečnostných udalostiach. Aplikácia by ich mala vedieť posielať do externého monitorovacieho systému v štruktúrovanej forme, obsahujúcej ideálne:
  • dátum a čas
  • IP adresu a port
  • identitu používateľa
  • všetky detaily ku bezpečnostnému incidentu
• používateľské / transakčné logy, audit trail – informácie o akciách, vykonaných používateľmi. Mali by byť vo forme, prístupnej bežným používateľom systému, napr. cez administrátorské webové rozhranie k aplikácii.

Oblasť 2 – Vývoj

Pravidlo 2.1. – Poznajte programovací jazyk, ktorý používate, aj z bezpečnostného hľadiska

Bezpečnosť nekončí iba pri samotnom dizajne. Bezpečnostné zásady z dizajnovania musia byť pretavené aj do procesu vývoja samotného softvéru, teda reálneho programovania. Prakticky sa treba zamerať na niekoľko zásad bezpečného programovania.

Pri používaní akéhokoľvek programovacieho jazyka a jemu zodpovedajúcemu frameworku sa zamerajte na najlepšiu programovaciu prax pri jeho používaní, ako aj na existenciu známych zraniteľností v jazyku alebo frameworku a spôsoby ich mitigácie. To isté sa týka aj prostredia, v ktorom programujete a jednotlivých závislostí. Zároveň je dobré dodržať zásady, uvedené v nasledovných kapitolách.

Pravidlo 2.2. – Validujte dáta na vstupe

Validácia vstupov NEMÁ byť zameraná na ochranu pred určitým typom útokov, jej účelom je mať na vstupe kvalitné dáta.

Validáciu vstupov treba robiť čo najskôr – najlepšie priamo v bode, kde sú dáta prijaté. Zamerajte sa na tzv. pozitívnu bezpečnosť – vytvárajte namiesto blacklistov whitelisty – teda vytvorte si napríklad zoznam dovolených aktivít namiesto zakázaných. Vytvoríte tak jasné pravidlá, kedy bude zakázané všetko okrem toho, čo explicitne dovolíte.

Pozor na validáciu regulárnymi výrazmi – treba sa uistiť, že regulárny výraz pokrýva celý vstup od začiatku po koniec, vrátane prípadných “cr” a “lf” znakov, ktoré by používateľ mohol zaslať. Uistite sa, že váš regulárny výraz nemá zraniteľnosti vyplývajúce z použitia špeciálnych znakov vo vstupe.

V ideálnom prípade použite validačné funkcie frameworku.

Pravidlo 2.3. – Výstupné dáta ošetrujte tak, aby nedošlo k úniku informácií

Všetky výstupy treba ošetriť, prispôsobiť špecifikám miesta, kam sú zasielané. Tomuto procesu sa hovorí escapovanie. Napríklad pri výstupe do CSV súboru si typicky treba dať pozor na čiarky, úvodzovky a entery.

Na rozdiel od validácie vstupov, escapovanie sa robí čo najneskôr, tesne pred odoslaním alebo uložením dát. Zamerajte sa najmä na injekčné zraniteľnosti – SQL injekcie, vykonávanie shell príkazov, narušenie formátu pri ukladaní do súborov (TXT, XML, HTML, CSV), cross site scripting pri výstupe do prehliadača, takisto aj na mená súborov, ktoré môžu obsahovať vykonateľný kód. 

Na escapovanie si nevytvárajte vlastné funkcie. Použite kód, ktorý je zaužívaný – svojim vlastným programovaním môžete stratiť nielen veľa času, ale aj spraviť chyby, ktoré zabezpečia nefunkčnosť vašich bezpečnostných funkcií.

Nespadnite do pasce falošného pocitu bezpečia, že platforma alebo framework, ktorý používate, zabraňuje vzniku zraniteľností typu sql injekcia alebo cross site scripting. Veľmi často je možné ho použiť spôsobom, ktorý tieto zraniteľnosti umožní.

Pravidlo 2.4. – Dbajte na bezpečnosť viac-vláknových aplikácií

Pri viacvláknových aplikáciách je typickým problémom, ktorý treba od začiatku adresovať správnym návrhom, prístup ku zdieľaným premenným. Ak vlákna zdieľajú len jednu premennú a jej úpravy sú jednoduché, použite atomické typy. Akonáhle je však logika zložitejšia, treba použiť uzamykanie.

Na synchronizáciu používajte synchronizačné primitívy jazyka. Pri vnorenom uzamykaní dajte pozor na to, aby ste zámky získavali vždy v rovnakom poradí, inak môže dojsť k deadlocku.

Venujte pozornosť tomu, aby vo Vašej aplikácii nevznikla možnosť race conditions.

Pravidlo 2.5 – Aplikujte princíp minimálnych oprávnení

Ako pri dizajnovaní, tak aj pri vývoji sa držte princípov “defense-in-depth” a aplikujte viacero vrstiev bezpečnosti. Taktiež používajte princíp “Least privilege”, teda minimálnych práv používateľa v aplikácii tak, aby vykonával iba aktivity, ktoré vo svojej roli potrebuje.

Pravidlo 2.6 – Sessions riaďte bezpečným spôsobom

Pri manažmente sessions používajte overený framework namiesto toho, ktorý si naprogramujete sami. Ako v iných prípadoch, vyhnete sa tak chybám a nutnosti takýto framework udržiavať do budúcnosti. Kritická je najmä výmena session cookies pri prihlásení a odhlásení, zabránenie replay útokom, rýchlostné obmedzovanie pokusov o prihlásenie,  mechanizmy na zabránenie úniku session cookies. Všetky tieto veci majú známe frameworky vyriešené.

Pri session ID dbajte na to, aby jeho dĺžka bola najmenej 128 bitov (16 bajtov). Taktiež si dajte záležať na tom, aby entropia hodnoty session ID bola najmenej 64 bitov a bola dostatočne náhodná.

Kritické dáta nemôžu byť nikdy zdieľané alebo ukladané na strane používateľa. Ukladajte ich na serverovej strane na základe session cookie alebo prístupového tokenu.

Pravidlo 2.7 – Súbory manažujte bezpečne

Pri manažmente súborov dbajte na to, aby ste nepoužívali cesty a názvy súborov priamo od používateľa. Pôvodné meno súboru si uložte v databáze a ďalej pri práci so súborom používajte len jeho bezpečný identifikátor. Identifikátor validujte ako každý iný vstup.

Držte nahrané súbory mimo zdrojového kódu a ideálne v adresári, ktorý nie je priamo prístupný cez URL. Ak už musíte z nejakého dôvodu použiť webovo dostupný adresár, uistite sa, že názvy súborov neobsahujú absolútne žiadny vstup od používateľa a že v danom adresári je zakázané vykonanie skriptov.

Je vhodné limitovať veľkosť prenášaných súborov. Takisto dbajte na to, aby vaše súbory boli v stave “read-only”.

Pravidlo 2.8 – Ošetrujte chyby

Riadenie potrebujú aj chyby. Narábajte s nimi bezpečne a nezobrazujte ich používateľovi, ak o nich nemusí vedieť. Aj pri chybách, o ktorých vedieť musí, sa vyhnite úniku príliš veľkého množstva informácie.

Špeciálnym prípadom sú chyby pri registrácii, prihlásení, či obnove hesla. Tieto funkcie musia byť naprogramované tak, aby odozva na pokus o prihlásenie neexistujúceho používateľa, ako aj prihlásenie existujúceho používateľa so zlým heslom, vracali rovnaký chybový kód. Tým sa predíde možnej enumerácii používateľov. Pri registrácii je možné enumeráciu znemožniť použitím CAPTCHA.

Vyhnite sa známym nebezpečným funkciám (ako je notoricky známe “strcpy” v jazyku C) a majte na pamäti klasické chyby, ktoré môžu ohroziť prostredie, v ktorom sa vykonáva váš program – hlavne pretečenie zásobníka, únik zdrojov, neinicializované premenné a numerické chyby.

Pravidlo 2.9 – Svoju aplikáciu testujte interne aj externe

Samozrejmosťou každého bezpečného vývoja je testovanie. To musí prebiehať aj čiastkovo tak, aby boli odhalené chyby aj na nižších úrovniach programovania. Pri testovaní sa zamerajte aj na predošlé chyby, ktoré boli odhalené aby ste vylúčili ich prítomnosť v novej verzii. Po ukončení vývoja si dajte spraviť nezávislý audit a to formou preskúmania zdrojového kódu alebo penetračným testovaním (oba spôsoby môžu prebiehať manuálne alebo automatizovane).

Oblasť 3 – Nasadenie

Pravidlo 3.1. – Používajte aktualizovanú a nakonfigurovanú runtime architektúru

Pri runtime infraštruktúre sa ubezpečte, že je toto prostredie aktualizované a dobre nakonfigurované. Pri nasadzovaní produktu využívajte automatizačné nástroje (napr. ansible), ktoré dokážu jednoducho produkt nainštalovať spolu s jeho závislosťami a sprievodnými knižnicami. Dobrou praxou je používať kontajnery a kontajnerové orchestračné platformy (napr. Docker a Kubernetes).

Pravidlo 3.2. – Podpisujte inštalačné balíky

Inštalačné balíky podpíšte, pretože váš podpis zaručí používateľovi, že ide o legitímny softvér. Nezabúdajte ani na šifrovanie komunikácie, najmä ak ide o webové služby a produkty.

Oblasť 4 – Udržiavanie

Aj po nasadení vášho produktu bezpečnosť nekončí. Až reálne používanie softvéru ukáže nielen chyby alebo nedostatky funkcionality, ale aj bezpečnostných riešení, ktoré ste vo svojom produkte aplikovali.

Pravidlo 4.1 – Vydávajte pravidelné bezpečnostné aktualizácie

Vykonávajte pravidelné aktualizácie Vášho produktu, akonáhle objavíte bezpečnostnú zraniteľnosť, alebo je opravená bezpečnostná zraniteľnosť v niektorej z knižníc, aplikácií a iných závislostí, ktoré Váš produkt využíva.

Pravidlo 4.2. – Monitorujte svoju aplikáciu

Odporúčame, aby ste monitorovali váš produkt a zaznamenávali a vyhodnocovali neštandardné správanie. Implementujte do produktu možnosť pre používateľa hlásiť vám neštandardné správanie, problémy s funkcionalitou a podobne.

Pravidlo 4.3 – Dbajte na kompatibilitu a dôveryhodné aktualizácie

Pri každej aktualizácii, či už bežnej alebo bezpečnostnej, dbajte na to, že produkt je kompatibilný s najnovšou verziou operačného systému zariadenia, na ktorý ho používateľ inštaluje. To isté sa týka aj komponentov a kontajnerov. Pri aktualizácii vášho softvéru dbajte na to, aby si používatelia mohli stiahnuť aktualizačné balíky dôveryhodnou a bezpečnou cestou.

Pravidlo 4.4. – Organizujte bug bounty programy

Veľmi dobrou praxou na hľadanie zraniteľností a vylepšovaní vášho produktu je tzv. “bug bounty program”. Je to forma súťaže, kde výrobca softvéru požiada výskumníkov alebo nadšencov, aby v jeho produkte našli zraniteľnosti alebo chyby, pričom im za to dá finančnú alebo inú odmenu. Výrobca softvéru tak môže nezávisle zistiť úroveň bezpečnosti svojho produktu a zároveň aj motivovať používateľov k používaniu takéhoto produktu.

Viac o nahlasovaní a manažmente zraniteľností sa môžete dočítať na https://www.sk-cert.sk/wp-content/uploads/2019/10/Navod_oznamovanie_zranitelnosti.pdf.

Ďalšie zdroje

Ak máte záujem neustále sa posúvať v bezpečnom programovaní ďalej, určite nevynechajte projekt OWASP, ktorý prináša v oblasti bezpečného programovania cenné rady a návody. Nájdete ich adresách:

• https://cheatsheetseries.owasp.org/. 
• https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/migrated_content

« Späť na zoznam