Bezpečnostné školenie OWASP TOP 10: Oplatí sa doňho investovať? Pozri sa na našu skúsenosť!

V kontexte viacerých nedávnych škandálov, totiž získava čoraz viac pozornosti. Aj samotných používateľov oveľa viac zaujíma, ako spoločnosti spracovávajú ich citlivé údaje a nakoľko sú tieto údaje u nich v bezpečí.

Pre nás v GoodRequest je téma bezpečnosti vždy prvoradá. Nie ako fráza, ale prirodzená súčasť akéhokoľvek interného procesu či projektu pre klienta. Aj preto sa v rámci nášho vzdelávacieho procesu tento rok sústredíme práve na zlepšovanie zabezpečenia našich mobilných a webových aplikácií a ochranu osobných údajov v nich. Aktuálne za sebou máme bezpečnostné školenie zamerané na najčastejšie zraniteľnosti webových aplikácií OWASP TOP 10.  V nasledujúcich riadkoch vám priblížim jeho priebeh a tiež dôvody prečo sa doňho oplatí, alebo neoplatí investovať.

Pre koho je bezpečnostné školenie určené?

Myslíte si, že bezpečnosť je výlučne záležitosťou backendistov? Opak je pravdou - existuje množstvo zraniteľností, ktoré využívajú aj nevhodne implementovaný frontend. Bezpečnosť aplikácie je veľmi komplexná záležitosť a je potrebné, aby aspoň tie najčastejšie zraniteľnosti poznali všetci členovia tímu a vedeli svoju aplikáciu voči nim chrániť. Na takomto školení sa presvedčíte aj na vlastné oči, že stačí jedna jediná chybička v tej najviac zapadnutej časti aplikácie a môže to viesť ku kompromitácii citlivých údajov používateľov. Preto sme sa rozhodli do školenia zapojiť všetkých členov webového teamu (od úplných juniorov až po leadov) a tiež aj zástupcu QA oddelenia.

Ak sa ti takýto prístup k vzdelávaniu a projekty na ktorých pracujeme páčia, pridaj sa k nám! 
‍V našom Backend/Frontend máme voľné miesto. Viac info o pracovnej pozícií Web developer 💻.

Aký má bezpečnostné školenie priebeh?

Našim školiteľom bol etický hacker Tomáš. Ku každému bodu z rebríčku OWASP TOP 10 (viac o tomto zozname nájdete na konci článku) povedal teoretický základ a následne sme si teóriu overili aj priamo v praxi, pri "hackovaní" testovacích aplikácií, navrhnutých priamo na demonštrovanie najznámejších zraniteľností. Samozrejmosťou bola aj diskusia o našich technických riešeniach a ich konfrontácia s Tomášovými skúsenosťami.

Pri školení sme si naplno uvedomili, aké je dôležité držať krok s dobou a používať tie najnovšie dostupné (ale zároveň aj dostatočne komunitou overené) technológie. Množstvo útokov je totiž realizovateľných iba na starších technológiách, prípadne ich neaktuálnych verziách.

Kvalita nášho technologického stacku sa ukázala v tom, že sa nám žiadnu z testovaných zraniteľností nepodarilo reprodukovať na našich produkčných aplikáciách a diskusia bola tak skôr v teoretickej rovine

V tejto rovine sme diskutovali o tom, ako by sme mohli ešte viac posilniť naše, už aj tak veľmi bezpečné aplikácie.

Kto je etický hacker?

Slovné spojenie "etický hacker" môže na prvý pohľad znieť ako oxymoron. Skutočne však existujú ľudia, ktorí sa vo voľnom čase snažia zlepšovať bezpečnosť aplikácií na internete a nemajú pritom žiadne nekalé úmysly. Poukazujú na zraniteľnosti, ktoré sa im podarilo odhaliť a tlačia na technologické spoločnosti, aby tieto chyby čo najskôr odstránili. Niekedy sa im za to ujde aj odmena (často len symbolická), ale väčšou satisfakciou pre nich je to, že práve im sa podarilo túto zraniteľnosť odhaliť skôr, ako hackerom z tej nelegálnej strany barikády. Tomáš sa s nami podelil o pár príbehov z kariéry etického hackera a bolo to naozaj veľmi zaujímavé počúvanie.

Čo sú penetračné testy a na čo slúžia?

Najlepšou ochranou pred zraniteľnosťami sú pravidelné penetračné testy aplikácie, ideálne vykonávané pri každom release na produkciu. S penetračnými testami od spoločnosti Citadelo už máme aj praktické skúsenosti, keďže testom podrobili niekoľko aplikácií z našej produkcie. Sme radi, že doposiaľ neodhalili žiadnu kritickú zraniteľnosť. Ich odporúčania nám však pomohli aplikácie ešte viac zabezpečiť aj proti situáciám, ktoré sú v súčasnosti možné skôr iba v teoretickej rovine, ale v budúcnosti by sa mohli stať reálnymi.

Overte, či Vaše údaje neboli ukradnuté (a pripravte sa byť prekvapení)

Viete, že si môžete jednoducho overiť, či vaše aktuálne heslo nebolo v minulosti bez vášho vedomia ukradnuté a zverejnené na internete? Na tejto webovej stránke sa po zadaní svojej e-mailovej adresy dozviete, či boli vaše prihlasovacie údaje niekedy kompromitované. Boli sme úprimne prekvapení, že každý z nás bol niekedy obeťou takéhoto úniku dát. Aj preto je extrémne dôležité, aby ste pre každú službu používali unikátne, dostatočne silné heslo, prípadne používali manažér hesiel. Samozrejme odporúčame používať dvojfaktorovú autorizáciu všade, kde je to možné (najmä na vašej primárnej e-mailovej schránke).

Vyskúšajte si "hackovanie" na vlastnej koži

Ak si budete chcieť vyskúšať niektoré zo zraniteľností vo svojom voľnom čase, určite to nerobte len tak na produkčných aplikáciách dostupných na internete. Je to ilegálne a mohli by ste z toho mať veľké problémy. Na tieto účely slúži napríklad projekt DVWA (Damn Vulnerable Web Application), ktorý obsahuje aplikáciu náchylnú na zraniteľnosti zo zoznamu OWASP TOP 10 a môžete si ho spustiť napríklad v prostredí virtuálnej mašiny. Obsahuje niekoľko úrovní náročnosti a tiež aj návod ako každú z nich prejsť.

Čo je to OWASP TOP 10?

Open Web Application Security Project je medzinárodná nezisková organizácia, ktorá je zameraná na zvyšovanie povedomia o najčastejších zraniteľnostiach aplikácií a spôsobom ako sa im vyhnúť. Každoročne preto zverejňujú zoznam TOP 10 najkritickejších zraniteľností, ktoré sú vždy aktualizované na základe aktuálnych trendov v oblasti zabezpečenia.

Tohtoročný rebríček OWASP TOP 10 2020 vyzerá nasledovne:

1. Injection

Útoky typu "Injection" sú zamerané na zneužitie neošetreného (resp. nedostatočne ošetreného) používateľského vstupu - keď slepo veríme dátam, ktoré do aplikácie vstupujú a útočníci to nasledovne vedia zneužiť na získanie prístupu k dátam, alebo dokonca k celej aplikácii. Je preto potrebné používať časom overené metódy na ošetrenie všetkých vstupov do aplikácie a po každom release aplikáciu na tieto zraniteľnosti dôkladne otestovať.

1. Broken Authentication

Túto zraniteľnosť najviac vystihuje známa múdrosť o znovu vynájdenií kolesa. Naivne sa pokúšať o vlastnú implementáciu autentifikácie je prakticky garanciou úspešného hackerského útoku. Spoľahnite sa radšej na overený štandard ako napríklad oAuth 2.0.

1. Sensitive Data Exposure

Ak už sa aj útočník dostane k obsahu databázy, je povinnosťou každého developera chrániť citlivé údaje používateľa proti ich ďalšiemu zneužitiu. Je preto potrebné napríklad heslá chrániť použitím správnej technológie asymetrického šifrovania s použitím kryptografickej soli a korenia.

1. XML External Entities (XEE)

Aj keď technológia XML už nie je najnovším trendom a jej používanosť postupne klesá, nesprávnou implementáciou parsovania XML dokumentov môžeme veľmi jednoducho svoju aplikáciu kompletne kompromitovať. Pred použitím akéhokoľvek XML parseru sa preto podrobne oboznámte s jeho dokumentáciou a ak nie je použitie XML vyslovene nutné, preferujte pri komunikácii radšej menej komplexný a tým aj bezpečnejší JSON.

1. Broken Access Control

Útoky typu Broken Access Control sa sústredia na zneužitie prístupových práv do systému (napr. prihlasovací token neprivilegovaného používateľa) na prístup do chránenej časti, ktorá by mala byť prístupná iba administrátorovi. Backend aplikácie by si mal pri každej požiadavke overiť, či má k danej funkcionalite používateľ prístup zabezpečiť prihlasovacie tokeny proti ich zneužitiu.

1. Security Misconfiguration

Veľmi častým problémom je nesprávne nastavenie samotného frameworku aplikácie, ktorý pri chybových stavoch na produkcii zverejní príliš podrobné chybové hlásenie, ktoré útočníkom pomáha pri ich snahe o prelomenie ochrany aplikácie. Pred nasadením aplikácie sa vždy ubezpečte, že ste vypli debug mód, odstránili všetky verejne prístupné logy a používateľom odosielate len všeobecné chybové hlášky (v žiadnom prípade nie výstup priamo z databázy).

1. Cross-Site Scripting

Ak majú používatelia aplikácie možnosť pridávať svoj vlastný obsah (napríklad komentáre, hodnotenia a pod.), útok typu XSS je veľmi častým problémom. Podobne ako pri útokoch typu Injection, každý používateľský vstup je nutné dôkladne validovať a využiť pritom overené nástroje, ktoré vám poskytuje vami zvolený framework.

1. Insecure Deserialization

Naozaj potrebujete v svojej aplikácii využívať serializáciu a deserializáciu? Ak áno, opäť je na mieste dôsledné preštudovanie dokumentácie serializačných knižníc a zváženie všetkých rizík, ktoré z toho vyplývajú.

1. Using Components With known Vulnerabilities

Wordpress je najviac používaným frameworkom na svetovom webe a väčšina zraniteľností je spôsobená neaktuálnymi verziami samotného Wordpressu, ale najmä pluginov a knižníc, ktoré využívajú. Nezabúdajte preto pravidelne aktualizovať všetky knižnice a rozšírenia vo vašich projektoch a tiež si ideálne spravte prehľad, či všetky tieto knižnice skutočne potrebujete.

1. Insufficient Logging And Monitoring

Ak už na vás niekto zaútočí, nie je nič horšie ako to, že o tom ani len netušíte. Čím skôr ste o prípadnom útoku informovaní, tým skôr na neho môžete reagovať a čo najviac znížiť jeho dopady.

Viac sa dozviete na oficiálnych stránkach projektu OWASP.

Oplatí sa investícia do bezpečnostného školenia?

Z nášho pohľadu je bezpečnosť aplikácií (a citlivých údajov v nich) v dnešnej dobe extrémne dôležitou témou. Pre firmu ktorá vyvíja takéto riešena, niet väčšej nočnej mory a horšieho marketingového prešľapu, ako titulky v novinách poukazujúce na to, že ste niečo zanedbali a kvôli vašej nedôslednosti prišlo množstvo ľudí o svoje súkromie. Myslíme si teda, že zveriť sa v tomto prípade do rúk profesionálom s dlhoročnými skúsenosťami je investícia, ktorá sa vám v budúcnosti určite vráti.

Na predchádzajúce riadky sa môžete pozrieť aj v kontexte konkrétnych aplikáciií a webových riešení ktoré vyvíjame. Vďaka tomu pochopíte ešte lepšie prečo k bezpečnosti pristupujeme takto zodpovedne a z akými dátami v rôznych projektoch pracujeme. Nahliadnite do nášho portfólia.