Poglavje 4 P2.1 Varnost spletnih aplikacij

P6.1

4.1 Odprtokodni projekt varnosti spletnih aplikacij OWASP

4.1.1 Uvod

Odprtokodni projekt varnosti spletnih aplikacij OWASP³ podpira odprta skupnost posameznikov in organizacij, ki vsem zainteresiranim akterjem omogoča razvoj, nakup in vzdrževanje aplikacij ter API-jev, ki jim lahko zaupamo.

Projekt OWASP ni povezan z nobenim tehnološkim podjetjem, vendar podpira tudi informiranost uporabnikov s komercialnimi tehnologijami za obvladovanje varnosti. Številni izdelki, ki nastanejo pod okriljem projekta OWASP, so rezultat sodelovanja različnih akterjev, transparentni in odprti:

orodja za preverjanje varnosti aplikacij (npr. ZAP) in standardi,
celovite knjige o preverjanju varnosti aplikacij, varnem razvoju programske opreme in varnem pregledovanju izvorne kode,
predstavitve in video posnetki,
kratka navodila za številne teme,
idr.

4.1.2 Trend največjih varnostnih tveganj spletnih aplikacij

Nezanesljiva programska oprema predstavlja veliko tveganje naši finančni, zdravstveni, obrambni, energijski in drugi infrastrukturi. Ker postaja naša programska oprema vedno bolj zapletena in medsebojno povezana, se težava doseganja ustrezne ravni varnosti aplikacij povečuje eksponentno. Zaradi hitrega razvoja sodobnih procesov razvoja programske opreme je odkrivanje in hitra odprava najbolj pogostih tveganj ključnega pomena. Ne smemo si namreč dovoliti, da bi v naših programskih rešitvah dopuščali obstoj sorazmerno preprostih varnostnih težav, ki so predstavljene v nadaljevanju kot 10 največjih varnostnih tveganj spletnih aplikacij (glej tabelo 4.1).

Čeprav je bil prvotni cilj projekta identifikacije 10 največjih varnostnih tveganj spletnih aplikacij preprosto povečati ozaveščenost med razvijalci in menedžerji podjetij, je postal de facto varnostni standard. Večja podjetja in organizacije, ki jim omenjena priporočila 10 največjih varnostnih tveganj spletnih aplikacij niso dovolj, lahko uporabijo dejanski standard ASVS.

Tabela 4.1: Največja varnostna tveganja spletnih aplikacij po zadnjih 8 letih ovrednotenja
Tveganje (2013)	Tveganje (2017)	Tveganje (2021)
A1:2013 - Vrivanje zlonamerne kode	A1:2017 - Vrivanje zlonamerne kode (A1:2013 + A7:2017)	A1:2021 - Neustrezen nadzor dostopa⁴ (A5:2017)
A2:2013 - Neustrezno preverjanje istovetnosti identitete in obvladovanje sej	A2:2017 - Neustrezno preverjanje istovetnosti identitete⁵ (A2:2013)	A2:2021 - Kriptografske napake⁶ (A3:2017)
A3:2013 - Izvajanje zlonamerne kode preko različnih domen (XSS)	A3:2017 - Izpostavljanje občutljivih podatkov⁷ (A6:2013)	A3:2021 - Vrivanje zlonamerne kode⁸ (A1:2017 + A7:2017)
A4:2013 - Nevarno neposredno referenciranje objektov	A4:2017 - XML zunanje entitete⁹ (XXE) (novo)	A4:2021 - Nevaren načrt¹⁰ (novo)
A5:2013 – Napačna varnostna konfiguracija	A5:2017 - Neustrezen nadzor dostopa (A4:2013 + A7:2013)	A5:2021 - Napačna varnostna konfiguracija¹¹ (A6:2017 + A4:2017)
A6:2013 – Izpostavljanje občutljivih podatkov	A6:2017 - Napačna varnostna konfiguracija (A5:2013)	A6:2021 - Ranljive in zastarele komponente¹² (A9:2017)
A7:2013 – Manjkajoča funkcijska raven nadzora dostopa	A7:2017 - Izvajanje zlonamerne kode preko različnih domen (XSS)¹³ (A3:2013 + A4:2013)	A7:2021 - Napake pri identifikaciji in avtentikaciji¹⁴ (A2:2017)
A8:2013 – Ponarejanje spletnih zahtev¹⁵ (CSRF) (odstranjeno)	A8:2017 - Nezanesljiva deserializacija¹⁶ (novo)	A8:2021 - Napake v programski opremi in integriteti podatkov¹⁷ (novo + A8:2017)
A9:2013 – Uporaba komponent z znanimi ranljivostmi	A9:2017 - Uporaba komponent z znanimi ranljivostmi¹⁸ (A9:2013)	A9:2021 - Varnostno beleženje in spremljanje napak¹⁹ (A10:2017)
A10:2013 – Nepotrjene preusmeritve in posredovanja²⁰ (odstranjeno)	A10:2017 - Neustrezno beleženje in spremljanje²¹ (novo)	A10:2021 - Ponarejanje zahtev na strani strežnika (SSRF)²² (novo)

V obdobju od 2013 do 2017 so se zgodile naslednje večje spremembe v uporabljenih tehnologijah in arhitekturi aplikacij, ki so tudi upoštevane v pregledu varnostnih tveganj iz leta 2017 (glej 2. stolpec v tabeli 4.1):

Mikrostoritve so implementirane večinoma v okoljih Node.js in Spring Boot ter zamenjujejo tradicionalne monolitne aplikacije. Mikrostoritve prihajajo z novimi varnostnimi izzivi, vključno z vzpostavitvijo zaupanja med mikrostoritvami, vsebniki, obvladovanjem zaupnosti idr. Za obstoječo izvorno kodo, ki se izvaja ob klicu API-ja ali REST spletne storitve, se ni nikoli pričakovalo, da bo dostopna na internetu. Arhitekturne predpostavke, ki so veljale v pisanju takšne kode, kot so npr. zaupanja vredni odjemalci, sedaj ne držijo več.
SPA aplikacije na eni strani, ki so razvite v JavaScript ogrodjih, kot sta Angular in React, omogočajo izdelavo zelo modularnih in bogatih aplikacij na strani odjemalca. Funkcionalnosti, ki se sedaj nahajajo na strani odjemalca in so bile včasih implementirane na strani strežnika, prinašajo nove varnostne izzive.
JavaScript je postal osrednji jezik svetovnega spleta skupaj z Node.js na strani strežnika in z modernimi spletnimi ogrodji, kot so Bootstrap, Electron, Angular in React, ki se izvajajo na strani odjemalca.

V obdobju od 2017 do 2021 so na voljo 3 nova tveganja, 4 tveganja s spremembami poimenovanja in obsega ter nekaj sprememb v vrstnem redu.

Eno od novih tveganj je A4:2021 - Nevaren načrt, ki se osredotoča na varnostne pomanjkljivosti pri načrtovanju. Potrebnih je namreč več varnih vzorcev načrtovanja, dobrih praks in referenčnih arhitektur. Tveganje A8:2021 - Napake v programski opremi in integriteti podatkov se osredotoča na težave, povezane s posodobitvami programske opreme, kritičnimi podatki in cevovodi CI/CD brez preverjanja integritete. Tveganje A10:2021 - Ponarejanje zahtev na strani strežnika (SSRF) se sicer še ne odraža med podatki pojavnosti, je pa nanj opozorila varnostna skupnost in naj bi v prihodnje predstavljalo eno večjih težav.

4.1.3 Ovrednotenje varnostnih tveganj aplikacije

Pregled varnostnih tveganj v letu 2021 temelji na podrobni analizi podatkov, kjer je 8 tveganj izbranih na podlagi obstoječih podatkov, 2 tveganji pa na podlagi ankete. Razlog za takšen pristop je v tem, ker so podatki in sama analiza le-teh vezana na preteklost, je zato uporabljena tudi neposredna povratna informacija iz skupnosti, kjer strokovnjaki za varnost aplikacij izpostavijo tveganja za katera menijo, da so problematična, vendar še niso prisotna med zgodovinskimi podatki.

Ko je bilo izbranih 10 največjih tveganj, so le-ta razvrščena glede na faktorje, ki so neposredno povezani z izkoriščanjem in učinkom posameznega tveganja:

Število povezanih CWE predstavlja vse CWE-je, ki so neposredno povezani s tveganjem. Seznam pogostih pomanjkljivosti CWE (angl. Common Weakness Enumeration) so pomanjkljivosti programske opreme, ki lahko povzročijo varnostne težave.
Stopnja pojavnosti²³ je delež aplikacij, ki so ranljive na CWE v okviru varnostnega tveganja.
Stopnja izkoriščanja je vrednost pridobljena iz CVSS, ki so dodeljena CVE-jem, preslikanim v CWE.
Učinek je vrednost pridobljena iz CVSS, ki so dodeljena CVE-jem, preslikanim v CWE.
Pokritost testiranja predstavlja delež aplikacij, ki so jih testirale vse organizacije za dano CWE.
Število pojavitev je skupno število ugotovljenih aplikacij, ki imajo CWE preslikan v varnostno tveganje.
Število CVE predstavlja vse CVE-je, ki so preslikani v CWE-je varnostnega tveganja. Pogoste ranljivosti in izpostavljenosti CVE (angl. Common Vulnerabilities and Exposures) je zbirka podatkov o javno razkritih varnostnih težavah.

Vrednosti faktorjev po tveganjih iz tabele 4.1 so povzete v tabeli 4.2 (z rdečo barvo so označene največje vrednosti posameznega faktorja), v nadaljevanju po so posamezna varnostna tveganja podrobneje predstavljena.

Tabela 4.2: Povzetek vrednosti faktorjev po tveganjih
Faktor	A1	A2	A3	A4	A5	A6	A7	A8	A9	A10
Število povezanih CWE	\(34\)	\(29\)	\(33\)	\(\color{darkred}{40}\)	\(20\)	\(3\)	\(22\)	\(10\)	\(4\)	\(1\)
Največja stopnja pojavnosti	\(\color{darkred}{55,97\ \%}\)	\(46,44\ \%\)	\(19,09\ \%\)	\(24,19\ \%\)	\(19,84\ \%\)	\(27,96\ \%\)	\(14,84\ \%\)	\(16,67\ \%\)	\(19,23\ \%\)	\(2,72\ \%\)
Povprečna stopnja pojavnosti	\(3,81\ \%\)	\(4,49\ \%\)	\(3,37\ \%\)	\(3,00\ \%\)	\(4,51\ \%\)	\(\color{darkred}{8,77\ \%}\)	\(2,55\ \%\)	\(2,05\ \%\)	\(6,51\ \%\)	\(2,72\ \%\)
Povprečna stopnja izkoriščanja	\(6,92\)	\(7,29\)	\(7,25\)	\(6,46\)	\(8,12\)	\(5,00\)	\(7,40\)	\(6,94\)	\(6,87\)	\(\color{darkred}{8,28}\)
Povprečen učinek	\(5,93\)	\(6,81\)	\(7,15\)	\(6,78\)	\(6,56\)	\(5,00\)	\(6,50\)	\(\color{darkred}{7,94}\)	\(4,99\)	\(6,72\)
Največja pokritost	\(\color{darkred}{94,55\ \%}\)	\(79,33\ \%\)	\(94,04\ \%\)	\(77,25\ \%\)	\(89,58\ \%\)	\(51,78\ \%\)	\(79,51\ \%\)	\(75,04\ \%\)	\(53,67\ \%\)	\(67,72\ \%\)
Povprečna pokritost	\(47,72\ \%\)	\(34,85\ \%\)	\(47,90\ \%\)	\(42,51\ \%\)	\(44,84\ \%\)	\(22,47\ \%\)	\(45,72\ \%\)	\(45,35\ \%\)	\(39,97\ \%\)	\(\color{darkred}{67,72\ \%}\)
Število pojavitev	\(\color{darkred}{318.487}\)	\(233.788\)	\(274.228\)	\(262.407\)	\(208.387\)	\(30.457\)	\(132.195\)	\(47.972\)	\(53.615\)	\(9.503\)
Število CVE	\(19.013\)	\(3.075\)	\(\color{darkred}{32.078}\)	\(2.691\)	\(789\)	\(0\)	\(3.897\)	\(1.152\)	\(242\)	\(385\)

4.1.4 A1:2021 - Neustrezen nadzor dostopa

4.1.4.1 Opis

Omejitve funkcionalnosti aplikacije nepooblaščenim uporabnikom so pogosto implementirane napačno. Napadalec lahko izkoristi te pomanjkljivosti pri nepooblaščenem dostopu do funkcij ali podatkov, kot je npr. dostop do računov drugih uporabnikov, dostop do občutljivih podatkov, spreminjanje podatkov drugih uporabnikov, spreminjanje pravic dostopa idr.

Neustrezen nadzor dostopa (angl. access control) se je iz 5. mesta v letu 2017 premaknil na 1. mesto v letu 2021. Kar \(94\ \%\) vseh preizkušenih aplikacij je vsebovalo določeno obliko neustreznega nadzora dostopa s povprečno stopnjo pojavnosti \(3,81\ \%\).

Faktor	Vrednost
Število povezanih CWE	\(34\)
Največja stopnja pojavnosti	\(55,97\ \%\)
Povprečna stopnja pojavnosti	\(3,81\ \%\)
Povprečna stopnja izkoriščanja	\(6,92\)
Povprečen učinek	\(5,93\)
Največja pokritost	\(94,55\ \%\)
Povprečna pokritost	\(47,72\ \%\)
Število pojavitev	\(318.487\)
Število CVE	\(19.013\)

4.1.4.2 Pogoste ranljivosti

Nadzor dostopa uveljavi varnostno politiko, kjer uporabniki ne morejo delovati izven predvidenih dovoljenj. Napake pri opredelitvi ustreznega nadzora dostopa običajno vodijo v nepooblaščeno razkritje informacij, spreminjanje ali uničenje vseh podatkov, izvajanje poslovne funkcije izven dovoljenj uporabnika. Pogoste pomanjkljivosti neustreznega nadzora dostopa so:

Kršitev načela najmanjših privilegijev (angl. least privilege) oz. privzete zavrnitve, kjer je treba dostop dovoliti zgolj določenim vlogam, vendar je na voljo vsem.
Napadalec lahko zaobide nadzor dostopa s spremembo URL naslova, notranjega stanja aplikacije, HTML strani ali z uporabo posebnega orodja za napad na API-je.
Omogočanje spreminjanja primarnega ključa na zapis drugega uporabnika, kar lahko omogoči pregled ali urejanje uporabniškega računa nekoga drugega.
Povišanje ravni dostopa (angl. privilege escalation), kjer napadalec pridobi raven dostopa uporabnika, ki se ni odjavil ali navaden uporabnik dobi raven dostopa skrbnika.
Manipulacija z metapodatki, kot je ponovna uporaba ali spreminjanje žetona JWT, piškotka oz. skritega polja na HTML strani ali zloraba razveljavitve JWT, s katerim napadalec doseže povišanje ravni dostopa.
Napačna konfiguracija izmenjave virov med različnimi izvori CORS omogoča nepooblaščen dostop do API-ja.
Preusmeritev brskanja neprijavljenih uporabnikov na zaščitene strani ali prijavljenega uporabnika na skrbniške strani. Dostop do POST, PUT in DELETE metod API-ja z manjkajočimi podatki za dostop.

Pogoste pomanjkljivosti CWE, povezane z neustreznim nadzorom dostopa, so:

4.1.4.3 Preprečevanje

Nadzor dostopa je učinkovit samo, če se uporablja zaupanja vredna izvorna koda poslovne logike strežnika ali API-ja, kjer napadalec ne more spremeniti nadzora dostopa ali metapodatkov. Nadaljnja priporočila za preprečevanje so:

Dostop do vseh virov, razen javnih, privzeto zavrnemo.
Mehanizem za nadzor dostopa implementirajte na enem mestu in ga uporabite na vseh potrebnih delih aplikacije, kar vključuje tudi zmanjšanja uporabe CORS.
Nadzor dostopa na ravni modela mora zagotavljati lastništvo zapisov, namesto da lahko uporabnik kreira, bere, posodablja ali briše poljuben zapis.
Enolične zahteve omejitev poslovnih aplikacij morajo biti uveljavljene na ravni domenskih modelov.
Onemogočanje prikaza seznama datotek v imeniku spletnega strežnika in odstranitev vseh nepotrebnih metapodatkov (npr. .git) iz imenika spletnega strežnika.
Beleženje napak pri nadzoru dostopa in obveščanje skrbnikov, ko je to treba (npr. ponavljajoče napake).
Omejitev dostopa (angl. rate limiting) do API-ja (npr. določeno število klicev na časovno enoto) za zmanjšanje vpliva potencialnega avtomatiziranega napada.
Po odjavi uporabnika moramo JWT žetone razveljaviti tudi na strani strežnika.

Razvijalci morajo v funkcionalne in integracijske teste vključiti tudi preverjanje nadzora dostopa.

Več o preprečevanju napada z neustreznim nadzorom dostopa lahko najdete v kratkih zapiskih OWASP: avtorizacija, testiranje pooblastitev idr.

4.1.4.4 Primeri scenarijev napadov

1. scenarij: Aplikacija uporablja nepreverjene podatke v klicu SQL, ki dostopa do podatkov o uporabniškem računu.

pstmt.setString(1, request.getParameter("racun"));
ResultSet results = pstmt.executeQuery( );

Potencialni napadalec v spletnem brskalniku preprosto spremeni vrednost parametra racun na poljubno vrednost, ki predstavlja uporabniški račun. Če se vrednost ne preverja ustrezno na strani strežnika, lahko napadalec dostopa do poljubnega uporabniškega računa.

http://spletna.stran.si/app/podrobnostiRacuna?racun=niMojRacun

2. scenarij: Napadalec preprosto vnese nov ciljni URL naslov, kjer se za dostop do skrbniških strani potrebuje skrbniške pravice.

http://spletna.stran.si/app/podrobnostiRacuna
http://spletna.stran.si/app/admin_podrobnostiRacuna

Če nepooblaščen uporabnik lahko dostopa do katerekoli od teh strani (glej vrstico 1 in 2), je to napačno delovanje aplikacije. Če navadni uporabnik, ki nima skrbniških pravic, lahko dostopa do skrbniške strani (glej vrstico 2), je to tudi napačno delovanje aplikacije.

4.1.5 A2:2021 - Kriptografske napake

4.1.5.1 Opis

Veliko spletnih aplikacij in API-jev svojih občutljivih podatkov (npr. finančni, zdravstveni podatki idr.) ne varuje dobro. Napadalci si lahko slabo zaščitene občutljive podatke prisvojijo oz. jih spremenijo in uporabijo za različne namene: goljufije s kreditnimi karticami, kraja identitete in druga kazniva dejanja. Občutljivi podatki so lahko ogroženi, če ne uporabimo dodatne zaščite, kot je npr. šifriranje shranjenih podatkov²⁴ ali pri prenosu, ter zahtevajo še posebej veliko pozornost, ko jih izmenjujemo s spletnim brskalnikom.

Kriptografske napake (angl. cryptographic failures) so se v letu 2021, glede na leto 2017, premaknile iz 3. mesta na 2. mesto in so bile prej poimenovane A3:2017 - Izpostavljanje občutljivih podatkov.

Faktor	Vrednost
Število povezanih CWE	\(29\)
Največja stopnja pojavnosti	\(46,44\ \%\)
Povprečna stopnja pojavnosti	\(4,49\ \%\)
Povprečna stopnja izkoriščanja	\(7,29\)
Povprečen učinek	\(6,81\)
Največja pokritost	\(79,33\ \%\)
Povprečna pokritost	\(34,85\ \%\)
Število pojavitev	\(233.788\)
Število CVE	\(3.075\)

4.1.5.2 Pogoste ranljivosti

Najprej so zahteve po zaščiti podatkov pri prenosu in pri shranjenih podatkih. Pri zaščiti gesel, številk kreditnih kartic, zdravstvenih zapisov, osebnih podatkov in poslovnih skrivnosti moramo biti bolj previdni, še posebej, če to področje obravnava kakšen zakon o varovanju podatkov (npr. EU GDPR). V takšnih primerih je treba pri naši aplikaciji preveriti:

Ali se kakšni podatki prenašajo v obliki navadnega besedila (angl. clear text)? To je povezano predvsem s protokoli HTTP, SMTP in FTP. Še posebej nevaren je zunanji promet do naše aplikacije preko interneta. Prav tako je treba preveriti ves notranji promet med sistemi za izravnavo obremenitve²⁵, spletnimi strežniki in ostalimi zalednimi sistemi.
Ali so občutljivi podatki shranjeni v obliki navadnega besedila, kar velja tudi za varnostne kopije.
Ali se uporabljajo starejši oz. neustrezni kriptografski algoritmi v obliki privzetih metod za šifriranje in dešifriranje ali v izvorni kodi starejših delov sistema?
Ali se uporabljajo privzete vrednosti kriptografskih ključev, šibkejši ključi za generiranje, manjka ustrezno obvladovanje ključev ali politika zamenjave ključev po določenem času?
Mogoče šifriranje ni vključeno na vseh ravneh aplikacije, npr. manjkajo kakšni elementi pri določeni skupini uporabnikov (npr. uporabniki spletnih brskalnikov)?
Ali odjemalci (npr. aplikacija, program za elektronsko pošto) ne preverjajo ustreznosti certifikata na strani strežnika?
Ali so inicializacijski vektorji prezrti, ponovno uporabljeni ali niso dovolj varni za kriptografski način delovanja? Ali je v uporabi nevaren način delovanja (npr. ECB)?
Ali se za kriptografske namene uporabljajo naključne vrednosti? Tudi če je izbrana pravilna funkcija, ali je uporabljena zadostna mera nepredvidljivosti?
Ali se uporabljajo zastarele zgoščevalne funkcije (npr. MD5, SHA1) ali celo nekriptografske zgoščevalne funkcije, ko se le-te potrebne?
Ali je možno sporočila o kriptografskih napakah izkoristiti za potencialne napade na sistem?

Pogoste pomanjkljivosti CWE, povezane s kriptografskimi napakami, so:

4.1.5.3 Preprečevanje

Pri preprečevanju izpostavljanja občutljivih podatkov je treba najmanj zadostiti naslednjim pogojem:

Podatke, ki jih aplikacija obdeluje, shranjuje ali prenaša, je treba razvrstiti v kategorije. Ugotoviti je treba, katera skupina podatkov je občutljiva glede na zakonske omejitve in poslovne potrebe.
Uveljavite kontrolo nad podatki glede na klasifikacijo v skupine.
Ne shranjujte občutljivih podatkov po nepotrebnem. Takšne podatke je treba čimprej zavreči ali jih s pomočjo šifriranja pretvoriti v varen zapis v obliki žetona²⁶. Podatkov, ki jih ne obdržimo, ni mogoče ukrasti.
Za prenos občutljivih podatkov se ne uporablja starih protokolov (npr. FTP, SMTP).
Vsi občutljivi shranjeni podatki morajo biti šifrirani.
Uporabite najnovejše in standardizirane algoritme ter protokole, vključno z ustreznim obvladovanjem ključev.
Vse podatke, ki se prenašajo, je treba zaščititi z varnimi protokoli (npr. TLS s prihodnjo varnostjo²⁷, prioritizacijo šifer na strežniku in varnimi parametri). Smiselno je tudi uveljavljanje šifriranja z uporabo direktiv, kot je npr. stroga varnost prenosa HTTP (HSTS).
Onemogočanje predpomnjenja za odzive, ki vsebujejo občutljive podatke.
Shranjevanje gesel z uporabo prilagodljivih algoritmov z uporabo naključnih vrednosti pri generiranju zgoščene vrednosti, kot je npr. Argon2, scrypt, bcrypt ali PBKDF2.
Inicilizacijski vektorji morajo imeti izbran način delovanja, kjer v večini primerov pomeni uporabo kriptografsko varnega generatorja naključnih števil CSPRNG.
Namesto šifriranja vedno uporabljati overjeno šifriranje (angl. authenticated encryption).
Neodvisno preverjanje učinkovitosti konfiguracije in nastavitev sistema.

Več o preprečevanju napada z izpostavljanjem občutljivih podatkov lahko najdete v kratkih zapiskih OWASP: zaščita prenosnega sloja, zaščita zasebnosti uporabnikov, shranjevanje gesel, kriptografska shramba, HSTS, testiranje šibke kriptografije.

4.1.5.4 Primeri scenarijev napadov

1. scenarij: Aplikacija šifrira številke kreditnih kartic z uporabo funkcionalnosti samodejnega šifriranja podatkov v podatkovni bazi. Vendar se ti podatki, ko jih zahtevamo, samodejno dešifrirajo, kar omogoča vrivanje zlonamerne SQL kode, kjer lahko napadalec pridobi številke kreditnih kartic v obliki navadnega besedila.

2. scenarij: Spletna stran ne uveljavlja TLS za vse strani oz. uporablja neustrezno šifriranje. Napadalec lahko spremlja omrežni promet (npr. v primeru brezžičnega omrežja), spremeni povezavo HTTPS v HTTP, prestreže podatke in ukrade piškote uporabniške seje. Napadalec nato uporabi pridobljen piškotek in ugrabi uporabnikovo sejo (uporabnik je prijavljen), kjer lahko dostopa ali spremeni zasebne podatke uporabnika. Napadalec lahko na ta način tudi spreminja prenesene podatke, npr. potrdilo o denarnem nakazilu ipd.

3. scenarij: Podatkovna baza z gesli uporablja enostavne zgoščene vrednosti brez uporabe naključnih vrednosti pri shranjevanju uporabniških gesel. Napaka pri modulu za nalaganje datotek napadalcu omogoča, da pridobi podatkovno bazo z gesli. Vse zgoščene vrednosti, kjer nismo uporabili naključne vrednosti, so izpostavljene, saj lahko za napad uporabimo mavrično tabelo²⁸ z vnaprej izračunanimi zgoščenimi vrednostmi. Zgoščene vrednosti, ki so nastale z uporabo enostavnih ali hitrih zgoščevalnih funkcij, lahko učinkovito razbijemo z uporabo procesorjev grafičnih kartic, tudi če smo pri generiranju uporabili naključne vrednosti.

4.1.6 A3:2021 - Vrivanje zlonamerne kode

4.1.6.1 Opis

Do vrivanja zlonamerne kode v različnih okoljih, kot so SQL, NoSQL, OS in LDAP, pride takrat, ko tolmač²⁹ (angl. interpreter) v obdelavo prejme podatke (npr. kot del ukaza ali poizvedbe), ki jim ne zaupamo. Zlonamerni podatki napadalca lahko preslepijo tolmača v izvajanje nepredvidenih ukazov oz. dostop do podatkov brez ustreznega pooblastila.

Vrivanje zlonamerne kode (angl. injection) je v letu 2021, glede na leto 2017, zdrsnil na 3. mesto. V \(94\ \%\) vseh aplikacij se je pojavila določena oblika vrivanja zlonamerne kode, s povprečno stopnjo pojavnosti \(19\ \%\).

Faktor	Vrednost
Število povezanih CWE	\(33\)
Največja stopnja pojavnosti	\(19,09\ \%\)
Povprečna stopnja pojavnosti	\(3,37\ \%\)
Povprečna stopnja izkoriščanja	\(7,25\)
Povprečen učinek	\(7,15\)
Največja pokritost	\(94,04\ \%\)
Povprečna pokritost	\(47,90\ \%\)
Število pojavitev	\(274.228\)
Število CVE	\(32.078\)

4.1.6.2 Pogoste ranljivosti

Spletna aplikacija je ranljiva na vrivanje zlonamerne kode, ko:

podatki, pridobljeni s strani uporabnika, niso preverjeni ali očiščeni nedovoljenih elementov³⁰,
se v tolmaču neposredno uporabljajo dinamične poizvedbe ali neparametrizirani klici brez odstranjevanja nedovoljenih elementov,
se uporabljajo zlonamerni podatki pri ORM iskalnih parametrih za pridobivanje dodatnih, občutljivih podatkov,
se pri izvajanju dinamičnih poizvedb, ukazov ali baznih procedur zlonamerni podatki neposredno uporabijo ali združijo z obstoječimi, tako da poizvedba SQL ali kakšen drug ukaz vsebuje strukturo in zlonamerne podatke.

Najbolj razširjena okolja za vrivanje zlonamerne kode so SQL, NoSQL, ukazi OS, ORM, LDAP in ostali. Koncept uporabe je enak pri vseh tolmačih ukazov. Najboljši način za odkrivanje ranljivosti vrivanja zlonamerne kode je pregled izvorne kode, sledi podrobno samodejno testiranje vseh parametrov, HTTP glave, URL naslovov, piškotkov, vhodnih podatkov JSON, SOAP in XML.

Pri pregledu kode lahko uporabimo tudi orodja za statično analizo izvorne kode (SAST) in orodja za dinamično testiranje aplikacij (DAST).

Pogoste pomanjkljivosti CWE, povezane z vrivanjem zlonamerne kode, so:

4.1.6.3 Preprečevanje

Pri preprečevanju vrivanja zlonamerne kode moramo poskrbeti, da so podatki ločeni od ukazov in poizvedb:

Najbolj se priporoča uporaba varne API dostopne točke, kjer se v celoti izloči neposredna uporaba tolmača ali se uporabi parametrizirani vmesnik ali ORM orodje za dostop do podatkov.

Namig: Tudi ko uporabljamo parametrizirane vmesnike, lahko še vedno dopuščamo vrivanje SQL kode v okviru baznih procedur, če PL/SQL ali T-SQL združuje poizvedbe in podatke ali izvaja zlonamerne podatke z ukazom EXECUTE IMMEDIATE ali exec().
Uporaba belega seznama³¹ (angl. whitelist) oz. dovoljenih vrednosti pri vrednotenju vhodnih podatkov. To ne predstavlja celovite zaščite, saj številne aplikacije zahtevajo uporabo posebnih znakov.
Pri vseh dinamičnih poizvedbah je treba posebne znake zamenjati z uporabo sintakse, specifične za izbran tolmač.

Namig: Pri jeziku SQL določenih elementov (npr. ime tabele, ime stolpca itd.) ne moremo zamenjati, zato so imena, posredovana s strani uporabnikov, lahko nevarna. To je znana težava npr. na področju programske opreme za generiranje poročil.
Pri SQL poizvedbah je treba uporabiti LIMIT in ostale SQL kontrolne omejitve, da preprečimo množično razkritje podatkov v primeru vrivanja SQL zlonamerne kode.

Več o preprečevanju vrivanja zlonamerne kode lahko najdete v kratkih zapiskih OWASP: preprečevanje vrivanja zlonamerne kode, preprečevanje vrivanja v SQL, preprečevanje vrivanja v Java kodi, parametrizacija poizvedb itd.

4.1.6.4 Primeri scenarijev napadov

1. scenarij: Aplikacija uporablja podatke, ki niso vredni zaupanja, pri pripravi naslednje ranljive SQL poizvedbe:

String poizvedba = "SELECT * FROM stranke WHERE idStranke='" + request.getParameter("id") + "'";

2. scenarij: Podobno lahko aplikacija, ki slepo zaupa uporabljenemu ogrodju (npr. Hibernate), uporablja ranljivo poizvedbo:

Query HQLpoizvedba = session.createQuery("SELECT * FROM stranke WHERE idStranke='" + request.getParameter("id") + "'");

Pri obeh primerih lahko napadalec spremeni vrednost parametra idStranke in iz spletnega brskalnika pošlje vrednost parametra ' or '1'='1, npr.

http://spletna.stran.si/api/pregledStrank?id=' or '1'='1

To spremeni pomen obeh poizvedb in vrne vse zapise v tabeli stranke. Še bolj nevarni napadi bi lahko podatke spremenili, jih izbrisali ali zahtevali izvajanje baznih procedur.

4.1.7 A4:2021 - Nevaren načrt

4.1.7.1 Opis

Nova ranljivost, ki se je pojavila na seznamu najbolj pogostih v letu 2021, nevaren načrt (angl. insecure design), se osredotoča na tveganja, povezana z načrtovalskimi in arhitekturnimi napakami. Za odpravo ranljivosti je treba pri razvoju programske opreme uporabljati načrtovanje groženj, uporabljati varne vzorce načrtovanja in referenčne arhitekture.

Faktor	Vrednost
Število povezanih CWE	\(40\)
Največja stopnja pojavnosti	\(24,19\ \%\)
Povprečna stopnja pojavnosti	\(3,00\ \%\)
Povprečna stopnja izkoriščanja	\(6,46\)
Povprečen učinek	\(6,78\)
Največja pokritost	\(77,25\ \%\)
Povprečna pokritost	\(42,51\ \%\)
Število pojavitev	\(262.407\)
Število CVE	\(2.691\)

4.1.7.2 Pogoste ranljivosti

Nevaren načrt zajema širok nabor ranljivosti, ki predstavlja različne slabosti v obliki manjkajoče ali neučinkovite zasnove nadzora. Zavedati se je treba tudi razlike med nevarnim načrtom in nevarno implementacijo, saj med obema obstajajo razlike v vzrokih za nastanek in načinu odpravljanja. Nevaren načrt lahko še vedno povzroči napake pri implementaciji, kar vodi do ranljivosti, ki jih je mogoče izkoristiti. Nevarnega načrta namreč ni mogoče odpraviti z idealno implementacijo, saj potrebni varnostni mehanizmi pred specifičnimi napadi niso na voljo pri implementaciji.

Pri razvoju programske opreme je zato smiselno slediti naslednjim korakom, predstavljenim v nadaljevanju.

4.1.7.2.1 Zajem zahtev in upravljanje virov

Pri zajemu zahtev se je z naročnikom treba podrobno pogovoriti o poslovnih zahtevah aplikacije, vključno z zahtevami glede zaupnosti, celovitosti, razpoložljivosti in pristnosti vseh podatkovnih virov ter poslovne logike. Upoštevati je treba izpostavljenost aplikacije in, poleg nadzora dostopa, tudi ločitev najemnikov (angl. multitenancy). Pripraviti je treba tehnične zahteve, vključno s funkcionalnimi in nefunkcionalnimi varnostnimi zahtevami. Potrebno je načrtovanje in prilagajanje proračuna, ki zajema celoten načrt, implementacijo, testiranje in delovanje, vključno z varnostnimi dejavnostmi.

4.1.7.2.2 Varen načrt

Varno načrtovanje je metodologija, ki nenehno ocenjuje grožnje in zagotavlja, da je izvorna koda robustno zasnovana in preizkušena pred znanimi metodami napadov. V proces izboljšanja je treba vključiti načrtovanje groženj, v toku podatkov, nadzoru dostopa in drugih varnostnih nadzorih se iščejo potencialne spremembe. Pri razvoju in implementaciji uporabniških zgodb se določijo pravilna stanja poteka in napake ter se zagotovi, da so odgovorni in vključeni akterji obveščeni, jih razumejo in se z njimi strinjajo. Predpostavke in pogoje za pričakovane tokove in tokove napak je treba analizirati in zagotoviti, da so točni in zaželeni. Vsi rezultati uporabniške zgodbe morajo biti dokumentirani. Iz napak se je potrebno učiti in ponujati spodbude za podporo izboljšavam. Varen načrt ni dodatek, niti orodje, ki bi ga lahko preprosto dodali programski opremi.

4.1.7.2.3 Življenjski cikel varnega razvoja

Varna programska oprema zahteva varen življenjski cikel razvoja, določeno obliko vzorca varnega načrta, metodologijo, zaščiteno knjižnico komponent, orodja in načrtovanje tveganj. Varnostne strokovnjake je treba vključiti že na začetku projekta razvoja programske opreme in naj bodo prisotni skozi celoten projekt in med vzdrževanjem programske opreme. Razmislite lahko tudi o uporabi zrelostnega modela programske opreme OWASP Software Assurance Maturity Model (SAMM).

Pogoste pomanjkljivosti CWE, povezane z nevarnim načrtom, so:

4.1.7.3 Preprečevanje

Vzpostavitev in uporaba življenjskega cikla varnega razvoja (angl. secure development lifecycle) ter vključitev varnostnih strokovnjakov pri ocenjevanju in oblikovanju nadzorov, povezanih z varnostjo in zasebnostjo.
Uporaba knjižnic varnih vzorcev načrtovanja (angl. secure design patterns).
Uporaba načrtovanja groženj za kritično preverjanje pristnosti, nadzor dostopa, poslovno logiko in tokove varnostnih ključev.
V uporabniške zgodbe se vključi varnostni jezik in kontrole.
Preverjanje verodostojnosti na vsaki ravni aplikacije (od zalednega dela do uporabniškega vmesnika).
Za potrditev odpornosti kritičnih tokov na načrt groženj se pripravijo testi enot in integracijski testi. Za vsako raven aplikacije se pripravi primer uporabe in primer zlorabe.
Ločitev na sistemske in omrežne ravni, glede na potrebe po izpostavljenosti in zaščiti.
Strogo ločevanje najemnikov na vseh ravneh že v načrtu programske opreme.
Omejitev porabe virov po uporabniku in storitvi.

4.1.7.4 Primeri scenarijev napadov

1. scenarij: Proces obnovitve poverilnic lahko vključuje vprašanja in odgovore, kar je v okviru smernic za digitalno identiteto NIST 800-63b prepovedano. Vprašanjem in odgovorom ni mogoče verjeti kot dokaz identitete, saj lahko več oseb pozna odgovore, zato so tudi prepovedani. Takšno izvorno kodo je treba odstraniti in nadomestiti z bolj varnim načrtom.

2. scenarij: Veriga kinodvoran omogoča popuste pri skupinskih rezervacijah do največ 15 oseb, preden zahtevajo plačilo depozita. Napadalec bi lahko zlorabil takšen načrt s poskusom rezervacije 600 sedežev v vseh kinodvoranah naenkrat in posledično povzročil večjo izgubo dohodka verigi kinodvoranam.

3. scenarij: Spletna trgovina nima zaščite pred boti, ki kupujejo najboljše grafične kartice in jih nato preprodajajo preko dražb. S tem se ustvari reklama za izdelovalce grafičnih kartic in lastnike trgovskih verig, po drugi strani pa težave za kupce, ki grafičnih kartic ne morejo dobiti za ustrezno ceno. Pri načrtovanju je zato treba opredeliti pravila proti delovanju botov, ki npr. opravijo nakup nekaj sekund po tem, ko je izdelek objavljen. Na ta način lahko prepoznamo neresnične nakupe in transakcije zavrnemo.

4.1.8 A5:2021 - Napačna varnostna konfiguracija

4.1.8.1 Opis

Napačna varnostna konfiguracija (angl. security missconfiguration) je pogosto posledica uporabe privzetih nezaščitenih konfiguracij, nepopolne ali ad hoc konfiguracije, uporabe odprte oblačne shrambe podatkov, napačne konfiguracije zaglavja HTTP, prikazovanja podrobnih sporočil o napakah, ki vsebujejo občutljive informacije. Ne samo da moramo poskrbeti za varno konfiguracijo operacijskega sistema, uporabljenih ogrodij, knjižnic in aplikacije, ampak moramo tudi pravočasno poskrbeti za popravke in nadgradnje.

Napačna varnostna konfiguracija se je iz 6. mesta v letu 2017 premaknila na 5. mesto v letu 2021. Z vedno večjo uporabo nastavljivih komponent programske opreme ta premik navzgor niti ni presenetljiv. Ranljivost je bilo mogoče zaslediti v \(90\ \%\) preizkušenih aplikacijah, s povprečno stopnjo pojavnosti \(4\ \%\).

Faktor	Vrednost
Število povezanih CWE	\(20\)
Največja stopnja pojavnosti	\(19,84\ \%\)
Povprečna stopnja pojavnosti	\(4,51\ \%\)
Povprečna stopnja izkoriščanja	\(8,12\)
Povprečen učinek	\(6,56\)
Največja pokritost	\(89,58\ \%\)
Povprečna pokritost	\(44,84\ \%\)
Število pojavitev	\(208.387\)
Število CVE	\(789\)

4.1.8.2 Pogoste ranljivosti

Pogosti vzroki za ranljivost aplikacije:

Pomanjkanje ustrezne varnostne zaščite v poljubnem delu sklada aplikacije ali napačno konfigurirane pravice storitev v oblaku.
Omogočene oz. nameščene so nepotrebne funkcionalnosti (npr. odprta različna vrata, storitve, strani, računi ali pravice za dostop)
Omogočeni in nespremenjeni so privzeti uporabniški računi in njihova gesla.
Obvladovanje napak uporabnikom razkriva preveč podrobna sporočila o napakah.
Pri nadgrajenih sistemih so najnovejše varnostne funkcije onemogočene oz. nepravilno nastavljene.
Varnostne nastavitve aplikacijskih strežnikov, ogrodjih za razvoj (npr. Struts, Spring, ASP.NET idr.), knjižnicah in podatkovnih bazah niso nastavljene na varne vrednosti.
Strežnik ne pošilja direktiv oz. varnostnih podatkov v glavi ali vrednosti niso nastavljene na varne.
Programska oprema je zastarela oz. ranljiva (podrobnosti so v A6:2021 - Ranljive in zastarele komponente).

Brez procesa usklajevanja in ponovljivega postopka varnostnih konfiguracij aplikacij so sistemi veliko bolj ogroženi.

Pogoste pomanjkljivosti CWE, povezane z napačno varnostno konfiguracijo, so:

4.1.8.3 Preprečevanje

Pri namestitvi programske opreme je treba poskrbeti za varnostno konfiguracijo, kar vključuje:

Postopek zavarovanja aplikacije mora biti ponovljiv, tako da omogoča enostavno in hitro namestitev v drugo okolje, ki je ustrezno zavarovano. Razvojno, testno in produkcijsko okolje naj bodo nastavljeni enako, z različnimi uporabniškimi računi za posamezno okolje. Postopek mora biti avtomatiziran, da se zmanjša potreben napor za nastavitev novega varnega okolja.
Razvojna platforma mora biti minimalna, brez nepotrebnih funkcionalnosti, komponent, dokumentacije in testnih primerov. Nepotrebne funkcionalnosti in ogrodja je treba odstraniti ali jih sploh ne nameščati.
Naloga pregledovanja in posodobitev konfiguracij je del procesa za upravljanje s popravki (glej A6:2021 - Ranljive in zastarele komponente), kjer je treba obravnavati vsa varnostna priporočila, posodobitve in popravke. Še posebej je treba poskrbeti za pregled pravic v oblaku.
Arhitektura aplikacije naj bo večnivojska, kjer učinkovito in varno ločimo različne komponente oz. najemnike aplikacije z uporabo segmentacije, vsebnikov ali varnostnih skupin v oblaku.
Posredovanje varnostnih direktiv odjemalcu.
Avtomatiziran proces preverjanja učinkovitosti konfiguracij in nastavitev v vseh okoljih.

Več o preprečevanju napada z napačno varnostno konfiguracijo lahko najdete v kratkih zapiskih OWASP: testiranje upravljanja konfiguracij, testiranje kod napake, varne direktive.

4.1.8.4 Primeri scenarijev napadov

1. scenarij: Aplikacijski strežnik ima privzeto nameščene testne aplikacije, ki iz produkcijske postavitve niso odstranjene. Testne aplikacije imajo znane varnostne pomanjkljivosti, ki jih napadalec uporabi za napad na strežnik. Če je ena od teh aplikacij skrbniška konzola in privzetih računov nismo spremenili, se lahko napadalec prijavi z privzetim uporabniškim imenom in geslom ter ogrozi sistem.

2. scenarij: Brskanje po datotekah imenika na spletnem strežniku ni onemogočeno. Napadalec ugotovi, da lahko dostopa do seznama datotek v imeniku. Napadalec nato najde in prenese prevedene razrede Java (.class), ki jih z obratnim inženiringom pretvori v izvorno kodo, kjer odkrije resno pomanjkljivost v kontrolnem toku aplikacije in jo izkoristi.

3. scenarij: Konfiguracija aplikacijskega strežnika omogoča prikaz zelo podrobnih sporočil o napakah (npr. celotna sled napake), ki so prikazana uporabniku. Na ta način so lahko razkriti občutljivi podatki ali potencialne težave, kot je verzija uporabljenih komponent, za katere je znano, da so ranljive.

4. scenarij: Ponudnik storitve v oblaku ima privzeto omogočeno dovoljenje za skupno rabo ostalim uporabnikom sistema. Na ta način je omogočen dostop do občutljivih podatkov, shranjenih v oblaku.

4.1.9 A6:2021 - Ranljive in zastarele komponente

4.1.9.1 Opis

Komponente, kot so knjižnice, ogrodja in drugi programski moduli, se izvajajo z istimi pravicami dostopa kot aplikacija, ki jih uporablja. Če se izkoristi ranljivost ene izmed komponent, lahko takšen napad povzroči resno izgubo podatkov ali celo prevzem strežnika. Aplikacije in API-ji, ki uporabljajo komponente z znano ranljivostjo, lahko ogrozijo varnost aplikacije in omogočajo različne napade in vplive.

Ranljive in zastarele komponente (angl. vulnerable and outdated components) je bila na 2. mestu glede na anketo med skupnostjo varnostnih strokovnjakov in tudi na podlagi analize podatkov se je uvrstila na seznam najpogostejših tveganj. Ranljive komponente so znana težava, kjer ocenjujemo tveganje ter je edino tveganje, ki nima nobenih preslikav med CVE in CWE, zato sta uporabljeni privzeti stopnji izkoriščanja in učinka z vrednostjo 5.

Faktor	Vrednost
Število povezanih CWE	\(3\)
Največja stopnja pojavnosti	\(27,96\ \%\)
Povprečna stopnja pojavnosti	\(8,77\ \%\)
Povprečna stopnja izkoriščanja	\(5,00\)
Povprečen učinek	\(5,00\)
Največja pokritost	\(51,78\ \%\)
Povprečna pokritost	\(22,47\ \%\)
Število pojavitev	\(30.457\)
Število CVE	\(0\)

4.1.9.2 Pogoste ranljivosti

V naslednjih scenarijih obstaja velika verjetnost, da je spletna aplikacija ranljiva:

Ne poznate vseh različic uporabljenih komponent (na strani odjemalca in strežnika). To vključuje komponente, ki jih uporabljate neposredno in vse odvisnosti od uporabljenih komponent.
Programska oprema je ranljiva, zastarela ali ni več podprta. Sem spadajo operacijski sistemi, spletni in aplikacijski strežniki, sistemi za upravljanje podatkovnih baz (DBMS³²), aplikacije, API-ji, vse komponente, izvajalna okolja in knjižnice.
Ne izvajate rednega preverjanja ranljivosti in niste naročeni na varnostna obvestila, povezana s komponentami, ki jih uporabljate.
Osnovna platforma, ogrodja in odvisnosti niso posodobljeni na zadnje verzije. To se običajno zgodi v okoljih, kjer se nameščanje popravkov izvaja mesečno ali ob četrtletju v okviru procesa za obvladovanje sprememb, kar podjetje po nepotrebnem izpostavlja identificiranim varnostnim tveganjem več dni ali celo mesecev.
Razvijalci programske opreme ne testirajo združljivosti posodobljenih in nadgrajenih knjižnic.
Konfiguracija komponent ni zaščitena, kot je podrobneje predstavljeno v A5:2021 - Napačna varnostna konfiguracija.

Pogosta pomanjkljivost CWE, povezana z ranljivimi in zastarelimi komponentami, je:

CWE-1104: Use of Unmaintained Third Party Components.

4.1.9.3 Preprečevanje

V uporabi mora biti proces obvladovanja popravkov (angl. patch management process):

Poskrbimo, da so neuporabljene odvisnosti, nepotrebne funkcionalnosti, komponente, datoteke in dokumentacije odstranjene.
Nenehno beleženje različic komponent na strani odjemalca in strežnika (npr. ogrodja, knjižnice) ter njihovih odvisnosti z uporabo orodij versions, Dependency Check, Retire.js idr. Stalno je treba spremljati spletne strani, kot sta VCE (The MITRE Corporation 2018) in NVD (National Institute of Standards and Technology 2018), kjer so objavljene ažurne ranljivosti obstoječih komponent. Priporoča se uporaba orodij za kompozicijo programske opreme, ki omenjeni proces avtomatizirajo. Za komponente, ki jih uporablja aplikacija, je smiselna tudi prijava na opozorila po elektronski pošti.
Komponente, ki jih uporabljate v aplikaciji, prenašajte zgolj preko varnih povezav iz uradnih virov. Izbirajte podpisane pakete, da se zmanjša verjetnost nepooblaščenega spreminjanja komponent pred uporabo v aplikaciji.
Spremljate knjižnice in komponente, ki se jih ne vzdržuje več ali popravki starejših verzij niso na voljo. Če posodobitev ni mogoča, razmislite o uporabi navideznih popravkov (angl. virtual patch) za spremljanje, odkrivanje in zaščito pred pomanjkljivostmi.
V vsaki organizaciji mora biti opredeljen stalni načrt za spremljanje, identificiranje in izvedbo popravkov ali konfiguracij za celotni življenjski cikel aplikacije.

Več o preprečevanju napada z uporabo komponent z znanimi ranljivostmi lahko najdete v kratkih zapiskih OWASP: preverjanje odvisnosti, najboljše prakse navideznih popravkov idr.

4.1.9.4 Primeri scenarijev napadov

1. scenarij: Komponente se običajno izvajajo z enakimi pravicami kot sama aplikacija, zato lahko napake v komponentah povzročijo resen učinek. Takšne napake so lahko naključne (npr. napaka pri kodiranju) ali namerne (npr. stranska vrata³³ v komponenti). Primeri nekaterih obstoječih ranljivosti v komponentah so:

CVE-2017-5638 je ranljivost pri ogrodju Struts2 z možnostjo izvajanja oddaljene kode in je bila uporabljena v številnih vdorih v aplikacije.
Internet stvari (IoT³⁴) je zelo težko ali celo nemogoče zaščititi, zato je zelo pomembno pravočasno uveljavljanje varnostnih popravkov (npr. pri biometričnih napravah).

Za iskanje sistemov, ki niso posodobljeni ali so napačno konfigurirani, obstajajo številna avtomatizirana orodja. Npr. s pomočjo iskalnika Shodan lahko poiščemo naprave, ki so še vedno ranljive na ranljivost Heartbleed, za katero obstaja popravek že od aprila 2014.

4.1.10 A7:2021 - Napake pri identifikaciji in avtentikaciji

4.1.10.1 Opis

Funkcionalnosti aplikacij, povezane s preverjanjem istovetnosti identitete in upravljanjem sej, so pogosto napačno implementirane, kar omogoča napad na gesla, ključe ali žetone sej oz. izkoriščanje drugih pomanjkljivosti pri izvajanju, kjer želimo začasno ali trajno pridobiti identiteto drugih uporabnikov.

V letu 2017 se je ranljivost imenovala neustrezno preverjanje istovetnosti identitete in je iz 2. mesta padla na trenutno 7. mesto v letu 2021.

Faktor	Vrednost
Število povezanih CWE	\(22\)
Največja stopnja pojavnosti	\(14,84\ \%\)
Povprečna stopnja pojavnosti	\(2,55\ \%\)
Povprečna stopnja izkoriščanja	\(7,40\)
Povprečen učinek	\(6,50\)
Največja pokritost	\(79,51\ \%\)
Povprečna pokritost	\(45,72\ \%\)
Število pojavitev	\(132.195\)
Število CVE	\(3.897\)

4.1.10.2 Pogoste ranljivosti

Potrditev uporabniške identitete, avtentikacija in obvladovanje sej so ključni pri zaščiti pred napadi zaradi neustreznega preverjanja istovetnosti identitete.

Spletna aplikacija je ranljiva na neustrezno preverjanje istovetnosti identitete, ko aplikacija:

Omogoča avtomatizirane napade, kjer napadalec s seznamom veljavnih uporabniških imen in gesel poskuša pridobiti dostop.
Omogoča napad z grobo silo (angl. brute force).
Dovoljuje uporabo slabih in splošno znanih gesel (npr. Password1 ali admin/admin).
Uporablja neučinkovito obnovo prijavnih podatkov in procese pozabljenega gesla, kot so odgovori na vprašanja, ki jih ni mogoče varno zaščititi.
Hrani geslo v obliki navadnega besedila ali slabo šifrirano (glej A2:2021 - Kriptografske napake).
Ne podpira večstopenjskega preverjanja istovetnosti identitete³⁵ (angl. multi-factor authentication).
Razkriva enolični identifikator seje v URL naslovu (npr. prepisovanje URL naslova).
Ne zamenja enoličnega identifikatorja seje po uspešni prijavi.
Napačno razveljavi enolični identifikator seje. Uporabniške seje ali žetoni za preverjanje pristnosti (npr. enkratna prijava³⁶ (angl. single sing-on (SSO))) niso pravilno razveljavljeni po odjavi iz sistema ali časovnem poteku.

Pogoste pomanjkljivosti, povezane z napakami pri identifikaciji in avtentikaciji, so:

4.1.10.3 Preprečevanje

Kjer je le mogoče, naj se uporablja večstopenjsko preverjanje istovetnosti identitete, ki onemogoči avtomatizirane napade in uporabo ukradenih prijavnih podatkov.
Pri nameščanju programske rešitve ne uporabljamo privzetih prijavnih podatkov, kar je pomembno še posebej za nadzorniške uporabniške račune.
Preverjanje ustreznosti slabih gesel, kjer nova oz. spremenjena gesla preverimo na seznamu najslabših gesel.
Prilagoditev dolžine gesel, njihove zahtevnosti in pravil zamenjave v skladu s priporočili NIST 800-63 B (National Institute of Standards and Technology, U.S. Department of Commerce 2017) v poglavju 5.1.1.
Zagotovitev, da so postopki registracije, obnovitve prijavnih podatkov in API poti odporni proti napadom za popis funkcionalnosti, kjer napadalcu za vsak neuspešni scenarij vrnemo isto sporočilo.
Omejitev oz. povečanje zakasnitve pri neuspešnih poskusih prijave v sistem. Vse neuspešne prijave je treba zabeležiti in skrbnika obvestiti ob vsakem poskusu napada.
Mehanizem za upravljanje sej naj bo implementiran na strani strežnika, ki za vsako sejo generira naključen enolični identifikator z visoko entropijo po prijavi. Enoličnih identifikatorjev seje ne vključujemo v naslov URL, shranjeni morajo biti varno in po odjavi, določenem času neaktivnosti oz. po času poteka jih je treba razveljaviti.

Več o preprečevanju neustreznega preverjanja istovetnosti identitete lahko najdete v kratkih zapiskih OWASP: preverjanje istovetnosti identitete, masovno preverjanje obstoječih uporabniških imen in gesel, pozabljeno geslo itd.

4.1.10.4 Primeri scenarijev napadov

1. scenarij: Uporaba seznama znanih gesel je pogost napad. Če aplikacija nima implementiranega mehanizma za onemogočanje takšnih avtomatiziranih napadov, se jo lahko uporabi kot dostopno točko za preverjanje ustreznosti večjega števila uporabniških imen in gesel.

2. scenarij: Večina napadov povezanih z neustreznim preverjanjem istovetnosti identitete se zgodi zaradi uporabe gesla kot edinega dejavnika. Če upoštevamo dobre prakse, mora aplikacija poskrbeti za obveščanje uporabnikov o periodičnem spreminjanju gesel. Organizacijam se priporoča, da uveljavljajo večstopenjsko preverjanje istovetnosti identitete, kot je priporočeno v NIST 800-63 (National Institute of Standards and Technology, U.S. Department of Commerce 2017).

3. scenarij: Časovni potek sej je napačno implementiran. Uporabnik za dostop do aplikacije uporabi računalnik v javni uporabi. Namesto da se iz aplikacije odjavi, uporabnik preprosto zapre zavihek spletnega brskalnika in zapusti računalnik. Napadalec uporabi isti računalnik 1 h kasneje in uporabnikova istovetnost identitete je še vedno uspešno potrjena.

4.1.11 A8:2021 - Napake v programski opremi in integriteti podatkov

4.1.11.1 Opis

Napake v programski opremi in integriteti podatkov (angl. software and data integrity failures) pogosto vodijo do izvajanja oddaljene kode (angl. remote code execution). Tudi če napake pri nezanesljivi deserializaciji ne povzročijo izvajanja oddaljene kode, se lahko uporabijo za izvajanje različnih napadov, vključno z napadi ponovitve, napadi vrivanja zlonamerne kode in napadi s stopnjevanjem ravni dostopa.

Napake v programski opremi in integriteti podatkov je novo tveganje v letu 2021 se osredotoča na posodobitve programske opreme, kritične podatke in cevovode CI/CD brez preverjanja integritete. Ima eno enega izmed največjih povprečnih učinkov.

Faktor	Vrednost
Število povezanih CWE	\(10\)
Največja stopnja pojavnosti	\(16,67\ \%\)
Povprečna stopnja pojavnosti	\(2,05\ \%\)
Povprečna stopnja izkoriščanja	\(6,94\)
Povprečen učinek	\(7,94\)
Največja pokritost	\(75,04\ \%\)
Povprečna pokritost	\(45,35\ \%\)
Število pojavitev	\(47.972\)
Število CVE	\(1.152\)

4.1.11.2 Pogoste ranljivosti

Napake v celovitosti programske opreme in podatkov se nanašajo na izvorno kodo in infrastrukturo, ki ne ščiti pred kršitvami integritete. Primer je uporaba vtičnikov, knjižnic ali modulov iz nezaupljivih virov, repozitorijev ali omrežij za dostavo vsebine CDN. Nevaren cevovod CI/CD lahko omogoči nepooblaščen dostop, izvajanje zlonamerne kode ali ogrožanje sistema. V zadnjem času tudi številne aplikacije vključujejo možnost samodejnega posodabljanja, kjer se posodobitve prenesejo brez zadostnega preverjanja integritete ter se uporabijo pri zaupanji vredni aplikaciji. Napadalci bi lahko potencialno naložili svoje posodobitve in jih posredovali naprej ter izvajali na vseh namestitvah.

Pogoste pomanjkljivosti, povezane z napakami v programski opremi in integriteti podatkov, so:

4.1.11.3 Preprečevanje

Edini varni arhitekturni vzorec je zavračanje serializiranih objektov iz nezaupljivih virov ali uporaba medijev za serializacijo, ki dovoljujejo uporabo zgolj enostavnih podatkovnih tipov. Če to ni izvedljivo, je smiselno upoštevati naslednja priporočila:

Uporaba digitalnih podpisov ali podobnih mehanizmov pri preverjanju spremembe podatkov oz. programske opreme iz pričakovanega vira.
Knjižnice in odvisnosti (npr. npm in Maven) morajo uporabljati zaupanja vredne repozitorije. Če imamo večji profil tveganja, se uporabi lastno gostovanje repozitorija, ki je dodatno preverjen.
Uporaba orodij (npr. OWASP Dependency Check ali OWASP CycloneDX) za preverjanje komponent glede znanih ranljivosti.
Prisotnost postopka pregleda sprememb izvorne kode in konfiguracije, s čimer se zmanjša možnost vnosq zlonamerne kode ali konfiguracije v postopek razvoja programske opreme.
Cevovod CI/CD ima ustrezno ločevanje, konfiguracijo in nadzor dostopa, da je zagotovljena celovitost izvorne kode, ki teče skozi proces gradnje in postavitve.
Nepodpisani in nešifrirani serializirani podatki se ne pošiljajo nezaupljivim odjemalcem brez preverjanja integritete in digitalnega podpisa za odkrivanje nedovoljenega poseganja ali neustrezne deserializacije.

4.1.11.4 Primeri scenarijev napadov

1. scenarij: Posodobitev brez podpisa. Številni domači usmerjevalniki in ostala strojna programska oprema naprav ne preverjajo posodobitev vdelane strojne programske opreme. Takšna programska oprema je lahko tarča napadalcev, kar predstavlja vedno večjo težavo. Pogosto namreč mehanizem za odpravo te težave ne obstaja, razen popravka v prihodnji različici in čakanje, da prejšnje različice zastarajo.

2. scenarij: Zlonamerna posodobitev SolarWinds. Znano je, da nekatere države napadajo mehanizme posodabljanja, kjer je eden izmed primerov napadov SolarWinds Orion. Podjetje, ki razvija programsko opremo, je imelo vzpostavljene varne procese celovitosti gradnje in posodabljanja. Kljub temu je prišlo do napada, kjer je podjetje nekaj mesecev posredovalo zlonamerne posodobitve več kot \(18.000\) organizacijam, kjer jih je bilo prizadetih nekaj \(100\). Šlo je za eno največjih takšnih kršitev v zgodovini.

3. scenarij: Nevarna deserializacija. Aplikacija v okolju React zahteva izvajanje mikrostoritev v okolju Spring Boot. V trenutni rešitvi je implementirana serializacija stanja uporabnika in posredovanje tega podatka pri vsaki zahtevi. Napadalec opazi podpis Java objekta "R00" in uporabi orodje Java Serial Killer za izvajanje oddaljene zlonamerne kode na aplikacijskem strežniku.

4.1.12 A9:2021 - Varnostno beleženje in spremljanje napak

4.1.12.1 Opis

Neustrezno beleženje in spremljanje, skupaj s pomanjkljivo ali neučinkovito integracijo z odzivom na incidente, omogoča napadalcem nadaljevanje njihovega napada, dostop do drugih sistemov, pridobivanje in celo uničenje podatkov. Večina študij dokazuje, da je povprečen čas za identifikacijo vdora več kot pol leta in da po navadi vdor zaznajo prej zunanji uporabniki kot pa notranji procesi beleženja in spremljanja.

Leta 2020 je bil povprečen čas, ki ga je podjetje potrebovalo za identifikacijo vdora v sistem, kar 287 dni (na področju zdravstva kar 329 dni), medtem ko je za odpravo vdora podjetje potrebovalo v povprečju 80 dni. Kibernetski napad se zgodi vsakih 39 s. Pri kar 34 % vdorov so vpleteni notranji akterji. 48 % vseh zlonamernih prilog elektronske pošte so bile datoteke Microsoft Office. Prvi računalniški virus The Creeper je bil odkrit že leta 1971.

Varnostno beleženje in spremljanje napak se je iz 10. mesta leta 2017 povzpelo na 9. mesto v letu 2021. To tveganje je lahko zelo zahtevno za testiranje in pogosto vključuje intervjuje v zvezi z odkritimi napadi med penetracijskimi testi. Za tveganje ne obstaja veliko CWE-jev, vendar je odkrivanje in odziv ključnega pomena.

Faktor	Vrednost
Število povezanih CWE	\(4\)
Največja stopnja pojavnosti	\(19,23\ \%\)
Povprečna stopnja pojavnosti	\(6,51\ \%\)
Povprečna stopnja izkoriščanja	\(6,87\)
Povprečen učinek	\(4,99\)
Največja pokritost	\(53,67\ \%\)
Povprečna pokritost	\(39,97\ \%\)
Število pojavitev	\(53.615\)
Število CVE	\(242\)

4.1.12.2 Pogoste ranljivosti

Do neustreznega beleženja, spremljanja in posledično prepoznega odziva skrbnika pride v naslednjih scenarijih:

Manjka beleženje dogodkov neuspešne prijave in transakcij z visoko dodano vrednostjo.
Opozorila in napake ne povzročijo ustreznih sporočil v dnevniških zapisih.
Sumljivih aktivnosti v dnevniških zapisih aplikacij in API-jev se ne spremlja.
Dnevniški zapisi so shranjeni zgolj lokalno.
Ustrezni pragovi za opozorila in procesi stopnjevanja niso vzpostavljeni ali so neučinkoviti.
Aplikacija ni sposobna zaznave, stopnjevanja ali opozarjanja v realnem času (oz. blizu realnega časa) na aktivni napad.
Aplikacija je občutljiva na uhajanje informacij, če je beleženje in generiranje opozoril vidno uporabniku ali napadalcu (podrobnosti v A1:2021 - Neustrezen nadzor dostopa).

Pogoste pomanjkljivosti, povezane z varnostnim beleženjem in spremljanjem napak, so:

4.1.12.3 Preprečevanje

Odvisno od tveganja shranjenih podatkov oz. procedure so potrebni naslednji ukrepi:

Zagotoviti je treba ustrezno raven beleženja vseh podatkov v zvezi s prijavami v sistem, napakami nadzora dostopa in preverjanjem vnosnih podatkov uporabnikov na strani strežnika. Z zbranimi podatki moramo biti sposobni identificirati sumljive ali zlonamerne uporabniške račune s pomočjo forenzične analize v dovolj kratkem času.
Dnevniški zapisi naj bodo zapisani v obliki, ki jo je mogoče vključiti v centralizirano informacijsko rešitev za upravljanje dnevniških zapisov.
Transakcije z visoko dodano vrednostjo morajo imeti na voljo revizijsko sled s kontrolami celovitosti, da preprečimo poseganje ali brisanje obstoječih dnevniških zapisov.
Vzpostavljeno je učinkovito spremljanje in generiranje opozoril, tako da so zlonamerne dejavnosti hitro odkrite in se na njih odzovemo pravočasno.
Testiranje učinkovitosti varovanja računalniškega sistema s simulacijo napadov in pregledi z orodji za dinamično testiranje aplikacij (npr. OWASP ZAP (The OWASP Foundation 2018c)).
Opredeliti je treba načrt za odziv ob vdoru v sistem in načrt za obnovitev sistema, kot je npr. NIST 800-61 r2.

Na trgu obstajajo številna komercialna in odprtokodna ogrodja:

za zaščito aplikacij, kot je npr. OWASP AppSensor (The OWASP Foundation 2018a),
požarni zid za spletne aplikacije, kot je npr. OWASP ModSecurity (The OWASP Foundation 2018b),
programska oprema za iskanje korelacij v dnevniških zapisih (npr. Elasticsearch, Logstash, Kibana) idr.

Več o preprečevanju napada z neustreznim beleženjem in spremljanje lahko najdete v kratkih zapiskih OWASP: beleženje.

4.1.12.4 Primeri scenarijev napadov

1. scenarij: Upravljalec spletne strani ponudnika zdravstvenih zavarovanj za otroke ni zaznal kršitev zaradi pomanjkanja spremljanja in beleženja. Zunanja oseba je ponudnika zdravstvenih zavarovanj obvestila, da je napadalec dostopal in spremenil nekaj tisoč občutljivih zdravstvenih zapisov več kot \(40.000\) otrok. Pregled po incidentu je ugotovil, da razvijalci spletnega mesta niso odpravili obstoječih varnostnih pomanjkljivosti. Ker beleženja in spremljanja sistema ni bilo prisotnega, je takšna kršitev potekala že več let.

2. scenarij: Večja indijska letalska družba je doživela vdor s krajo podatkov, ki je vključeval več kot desetletne osebne podatke milijona potnikov, vključno s podatki o potnih listih in kreditnih karticah. Do vdora je prišlo na gostovanju v oblaku pri enem od poslovnih partnerjev, ki je šele čez nekaj časa obvestil letalsko družbo.

3. scenarij: Večja evropska trgovska veriga je utrpela kršitev GDPR. Napadalec je izkoristil pomanjkljivost in pridobil več kot \(400.000\) zapisov o plačilih strank. Regulator je trgovsko verigo kaznoval z \(20\) milijoni evrov.

4.1.13 A10:2021 - Ponarejanje zahtev na strani strežnika (SSRF)

4.1.13.1 Opis

Ponarejanje zahtev na strani strežnika (angl. server-side request forgery (SSRF)) je v letu 2021 dodano na seznam največjih tveganj, kot prvo priporočila s strani skupnosti varnostnih strokovnjakov. Podatki kažejo razmeroma nizko stopnjo pojavnosti z nadpovprečno pokritostjo in učinkom.

Faktor	Vrednost
Število povezanih CWE	\(1\)
Največja stopnja pojavnosti	\(2,72\ \%\)
Povprečna stopnja pojavnosti	\(2,72\ \%\)
Povprečna stopnja izkoriščanja	\(8,28\)
Povprečen učinek	\(6,72\)
Največja pokritost	\(67,72\ \%\)
Povprečna pokritost	\(67,72\ \%\)
Število pojavitev	\(9.503\)
Število CVE	\(385\)

4.1.13.2 Pogoste ranljivosti

Napake SSRF se pojavijo vedno, ko spletna aplikacija pridobi oddaljeni vir brez preverjanja veljavnosti naslova URL, ki ga je posredoval uporabnik. Napadalcu omogoča, da prisili aplikacijo k pošiljanju zahteve na nepričakovani ciljni naslov, tudi če je le-ta zaščiten s požarnim zidom, VPN ali kakšno drugo vrsto seznama za nadzor dostopa do omrežja.

Ker sodobne spletne aplikacije uporabnikom omogočajo priročne funkcije, postane pridobivanje podatkov iz naslova URL običajen primer uporabe. Posledično se zaradi storitev v oblaku in zapletenosti arhitektur povečujeta tudi pojavnost in resnost SSRF.

Pogosta pomanjkljivost CWE, povezana s ponarejanjem zahtev na strani strežnika, je:

CWE-918: Server-Side Request Forgery (SSRF).

4.1.13.3 Preprečevanje

Razvijalci lahko preprečijo SSRF z izvajanjem naslednjih obrambnih postopkov:

na omrežni ravni,
- za zmanjšanje vpliva SSRF se funkcionalnost oddaljenega dostopa do virov porazdeli v ločenih omrežjih,
- uveljavitev privzetega zavračanja na požarnem zidu ali pravila za nadzor dostopa do omrežja, kjer je blokiran ves promet, razen nujno potrebnega,
- namigi:
  - vzpostavitev lastništva in življenjskega cikla pravil požarnega zidu na podlagi aplikacij,
  - beleženje vseh potrjenih in zavrnjenih omrežnih zahtev na požarnem zidu (glej A9-2021 - Varnostno beleženje in spremljanje napak),
na aplikacijski ravni,
- preverjanje vseh vhodnih podatkov, ki jih posreduje uporabnik,
- uveljavitev sheme URL, vrat in ciljnih lokacij s seznamom dovoljenih lokacij,
- uporabnikom ne posredujemo neobdelanih odgovorov,
- onemogočite preusmeritve HTTP,
- težav SSRF ne rešujte s seznamom zavrnitev ali regularnimi izrazi - napadalci lahko takšen seznam pridobijo in izvedejo obhod,
dodatni postopki,
- ne uporabljajte ostalih varnostno pomembnih storitev na čelnih sistemih (npr. OpenID) in nadzirajte lokalni promet na teh sistemih (npr. localhost),
- pri visokih varnostnih zahtevah uporabite šifriranje omrežja (npr. VPN) za čelne sisteme z namenskimi skupinami uporabnikov.

4.1.13.4 Primeri scenarijev napadov

Napadalci lahko uporabijo SSRF za napad na sisteme, zaščitene s požarnimi zidovi, in sicer:

1. scenarij: Pregledovanje vrat strežnikov v lokalnem omrežju. Če omrežna arhitektura ni porazdeljena, lahko napadalci preiščejo strukturo lokalnega notranjega omrežja in ugotovijo, katera vrata na notranjih strežnikih so odprta.

2. scenarij: Izpostavljenost občutljivih podatkov. Napadalec lahko dostopa do lokalnih datotek preko lokalnih storitev, kot je npr. file:///etc/passwd ali http://localhost:28017/.

3. scenarij: Dostop do shrambe metapodatkov storitev v oblaku. Večina ponudnikov storitev v oblaku ima shrambo metapodatkov, kot je npr. http://169.254.169.254/. Napadalec lahko metapodatke prebere in pridobi občutljive informacije.

4. scenarij: Ogrožanje internih storitev. Napadalec lahko zlorabi interne storitve za izvajanje nadaljnjih napadov, kot je npr. oddaljeno izvajanje kode RCE ali zavrnitev storitev DoS.

4.1.14 Priporočila za razvijalce

Če ste na področju varnosti spletnih aplikacij še začetnik ali ste z varnostjo že zelo dobro seznanjeni, je objava varne spletne aplikacije zelo naporno opravilo. V nadaljevanju je prikazanih nekaj priporočil s strani OWASP, ki jih lahko razvijalci uporabijo pri razvoju varnih spletnih aplikacij in API-jev.

4.1.14.1 Zahteve varnih spletnih aplikacij

Za razvoj varne spletne aplikacije je treba opredeliti, kaj pomeni varno v kontekstu aplikacije. OWASP priporoča uporabo standarda za preverjanje varnosti aplikacij ASVS kot vodnik pri nastavitvah varnostnih zahtev vaše aplikacije. Če nastopate v vlogi zunanjega izvajalca, se priporoča uporaba pogodbe o razvoju varne programske opreme (angl. secure software contract annex).

4.1.14.2 Arhitektura varnih spletnih aplikacij

Namesto da po končanem razvoju informacijske rešitve poskrbimo za varnost, je veliko bolj učinkovita skrb za varnost od samega začetka razvoja. OWASP priporoča uporabo izhodišč za načrtovanje varnosti aplikacije od začetka razvoja, ki jih najdemo v kratkih zapiskih OWASP.

4.1.14.3 Standardni varnostni nadzor

Oblikovanje učinkovitega varnostnega nadzora je zagotovo zahtevno opravilo. Z uporabo gradnikov za standardni varnostni nadzor si lahko močno poenostavimo razvoj varnih aplikacij in API-jev. OWASP priporoča uporabo smernic iz proaktivnega nadzora; številna novejša aplikacijska ogrodja pa že v osnovi podpirajo standardni in učinkovit varnostni nadzor za avtorizacijo, validacijo, preprečevanje CSRF ipd.

4.1.14.4 Varni življenjski cikel razvoja programske opreme

Za izboljšanje procesa razvoja, ki je v uporabi pri razvoju aplikacij in API-jev, OWASP priporoča uporabo zrelostnega modela za zagotavljanje kakovosti programske opreme (angl. software assurance maturity model (SAMM)). Predlagan model pomaga pri oblikovanju in izvajanju strategije varnosti programske opreme, saj je prilagojen posameznim tveganjem, s katerimi se sooča organizacija.

4.2 Osnovni varnostni pregled Demo aplikacije z OWASP ZAP

4.2.1 Priprava Demo aplikacije v lokalnem okolju

Z orodjem OWASP ZAP bomo preverili osnovno varnost naše aplikacije, ki jo poženemo na lokalnem računalniku in je na voljo na http://localhost:3000. Pred začetkom testiranja poskrbimo, da uporabljamo lokalno podatkovno bazo in lokalni strežnik, saj lahko v nasprotnem primeru porabimo vire, ki so nam na voljo v okviru brezplačnega gostovanja na Heroku in MongoDB Atlas.

Smiselno je izdelati tudi varnostno kopijo podatkovne baze (za to že imamo pripravljene skripte), saj bo pri aktivnem testiranju napolnjena s številnimi testnimi vrednostmi.

Pred testiranjem poskrbimo še za brisanje morebitnih starih podatkov in dodajanje novih testnih podatkov.

Podatke za uvoz lokacij in komentarjev že imamo na voljo, dodatno pa poskrbimo še za uporabnike. Pripravimo novo datoteko testni-uporabniki.json s testnim uporabnikom dejan@lavbic.net in geslom test.

data/testni-uporabniki.json

[
  {
    "name": "Dejan Lavbič",
    "email": "dejan@lavbic.net",
    "salt": "9981a3df943d041cf3e9d69332e3c87a",
    "hash": "177251e9308fdddfc52298964b2b0ad504351c9fd0090b81ca00bee3348ab23c84055f19126a1497a7f5eaf1e6d6780925a7824bc1c534d44f942a287211cf2c"
  }
]

Nato dopolnimo še skripte za pomoč pri uvozu podatkov uporabnikov.

package.json

{
  ...
    "scripts": {
    "start": "node server.js",
    "import:db-docker": "docker cp ./data/kulturne-dediscine.json web-dev-mongo-db:/kulturne-dediscine.json; docker cp ./data/testni-uporabniki.json web-dev-mongo-db:/testni-uporabniki.json; docker exec -it web-dev-mongo-db mongoimport --db Demo --collection Locations --mode upsert --upsertFields id --jsonArray --file kulturne-dediscine.json;  docker exec -it web-dev-mongo-db mongoimport --db Demo --collection Users --mode upsert --upsertFields email --jsonArray --file testni-uporabniki.json; docker exec -it web-dev-mongo-db rm -rf kulturne-dediscine.json",
    "delete:db-docker": "docker exec -it web-dev-mongo-db bash -c \"mongosh Demo --eval 'db.Locations.deleteMany({})'; mongosh Demo --eval 'db.Users.deleteMany({})'\"",
    "view:db-docker": "docker exec -it web-dev-mongo-db bash -c \"mongosh Demo --eval 'db.Locations.find()'; mongosh Demo --eval 'db.Users.find()'\"",
    "transfer:db-docker-atlas": "docker exec -it web-dev-mongo-db bash -c \"mongodump -h localhost -d Demo -o ./\"; docker exec -it web-dev-mongo-db bash -c \"mongorestore --drop --uri mongodb+srv://app@demo.548y4py.mongodb.net ./Demo/Locations.bson\"; docker exec -it web-dev-mongo-db bash -c \"mongorestore --drop --uri mongodb+srv://app@demo.548y4py.mongodb.net ./Demo/Users.bson\"; docker exec -it web-dev-mongo-db bash -c \"rm -rf ./Demo\""
  },
  ...
}

4.2.2 Podpora SSL

Pri razvoju spletnih aplikacij je ena izmed ključnih zahtev gostovanje aplikacije preko varnega protokola HTTPS, ki predstavlja razširitev protokola HTTP, saj ga pogosto imenujemo HTTP over TLS oz. HTTP over SSL.

Na takšen način je med strežnikom, ki gosti aplikacijo in odjemalcem, ki do nje dostopa, vzpostavljen varen kanal, ki uporabnike ščiti predvsem pred napadom s posrednikom (angl. man-in-the-middle attack).

Če boste gostovali svoje lastne rešitve, potem lahko enostavno in predvsem brezplačno uporabite storitev Let’s Encrypt, ki omogoča uporabo brezplačnega SSL certifikata za poljubno spletno domeno, kjer boste gostovali svojo aplikacijo. Večina ponudnikov spletnega gostovanja aplikacija omenjeno podporo že omogoča brezplačno.

V našem primeru lokalnega razvoja pa bomo s pomočjo knjižnice OpenSSL generirali lasten certifikat, ki ga bomo sami izdali in podpisali. Zaradi tega nas bo brskalnik sicer opozoril, da naša povezava ni varna, ker ne uporabljamo zaupanja vreden certifikat, vendar bo to za naše potrebe dovolj.

Kreirali bomo novo mapo cert, kjer bomo hranili privatni ključ server.key in certifikat server.cert. Pri procesu kreiranju vnesemo tudi zahtevana podatke certifikata.

$ mkdir cert
$ cd cert
$ openssl req -nodes -new -x509 -keyout server.key -out server.cert
Generating a 2048 bit RSA private key
...................................................................................................................................................................+++++
....................+++++
writing new private key to 'server.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) []:SI
State or Province Name (full name) []:Ljubljana
Locality Name (eg, city) []:Ljubljana
Organization Name (eg, company) []:UNI LJ
Organizational Unit Name (eg, section) []:FRI
Common Name (eg, fully qualified host name) []:localhost
Email Address []:dejan@lavbic.net

Omenjeno mape seveda ne bomo vključili v sistem git, zato dodamo izjemo.

.gitignore

node_modules
.env
.DS_Store
cert

Ker želimo zagon strežnika v načinu HTTPS zgolj na zahtevo, dodajmo okoljsko spremenljivko HTTPS, s katero to izrecno zahtevamo.

.env

# HTTPS
HTTPS=true

Pri zagonu strežnika, glede na vrednost okoljske spremenljivke HTTPS, poženemo HTTP oz. HTTPS strežnik.

server.js

/**
 * Start server
 */
if (process.env.HTTPS == "true") {
  const fs = require("fs");
  const https = require("https");
  https
    .createServer(
      {
        key: fs.readFileSync("cert/server.key"),
        cert: fs.readFileSync("cert/server.cert"),
      },
      app
    )
    .listen(port, () => {
      console.log(
        `Secure demo app started in '${
          process.env.NODE_ENV || "development"
        } mode' listening on port ${port}!`
      );
    });
} else {
  app.listen(port, () => {
    console.log(
      `Demo app started in '${
        process.env.NODE_ENV || "development"
      } mode' listening on port ${port}!`
    );
  });
}

Skladno s spremembo moramo dopolniti tudi okoljske spremenljivke aplikacije Angular.

angular/src/environments/environment.ts

export const environment = {
  apiUrl: "https://localhost:3000/api",
  production: false,
};

Prav tako dodamo HTTPS REST API strežnik za testiranje dostopne točke.

server.js

const swaggerDocument = swaggerJsDoc({
  definition: {
    ...
    servers: [
      {
        url: "https://localhost:3000/api",
        description: "Secure development server for testing",
      },
      {
        url: "http://localhost:3000/api",
        description: "Development server for testing",
      },
      {
        url: "https://sp-2022-2023.fly.dev/api",
        description: "Production server",
      },
    ],
    ...
  },
  ...
});

4.2.3 Zagon aplikacije

Pred začetkom testiranja prevedemo Angular aplikacijo v razvojnem okolju, kjer uporabljamo lokalno podatkovno bazo. Prav tako izbrišemo vse obstoječe podatke in podatkovno bazo napolnimo z novimi začetnimi podatki.

$ cd angular
$ ng build --output-path build --configuration development
...
$ cd ..
$ npm run delete:db-docker
...
$ npm run import:db-docker
...
$ npm run start
> demo@0.1.0 start
> node server.js
Demo app started in 'development mode' listening on port 3000!
Mongoose connected to 'mongodb://localhost/Demo'.

4.2.4 Konfiguracija orodja OWASP ZAP

Najprej nastavimo kontekst varnostnega preverjanja tako, da z dvojnim klikom v seznamu na levi strani izberemo Contexts → Default Context. Med nastavitvami izberemo Session → Contexts → 1: Default Context. V okviru nastavitev bomo varnostnemu pregledu bolj podrobno opredelili na kakšni tehnologiji temelji naša spletna aplikacija.

Pri 1: Technology izberemo:

DB → MongoDB,
Language → JavaScript,
OS → Linux, MacOS in Windows,
SCM → GIT.

Glede na to, da imamo na voljo dokumentiran REST API vmesnik, bomo uvozili tudi to OpenAPI specifikacijo, tako da v meniju izberemo Import → Import an OpenAPI definition from a URL in nastavimo URL Pointing to OpenAPI defn na spletni naslov Swagger datoteke, ki jo generira naša aplikacija https://localhost:3000/api/swagger.json ter potrdimo s klikom na gumb Import.

Na seznamu strani v okviru Sites se pojavijo vse metode naše dostopne točke, kjer ohranimo zgolj lokacijo https://localhost:3000, medtem ko gostovanje v oblaku na https://web-dev.fly.dev odstranimo.

Nato uvozimo nekaj spletnih naslovov aplikacije, ki jih bo lahko orodje ZAP uporabilo pri varnostnem pregledu, in sicer v meniju izberemo Import → Import a File Containing URLs.

data/url.txt

https://localhost:3000/
https://localhost:3000/login
https://localhost:3000/register
https://localhost:3000/about
https://localhost:3000/locations/65140319dae53b4c4262d2bc
https://localhost:3000/locations/65140319dae53b4c4262d52b
https://localhost:3000/locations/65140319dae53b4c4262da68

Vse spletne naslove, ki niso na našem naslovnem prostoru https://localhost:3000/ izločimo tako, da jih označimo in izberemo iz menija Exclude from → Proxy ter potrdimo s klikom na gumb Exclude.

Lahko pa na ravni celotne OWASP ZAP seje opredelimo, da se naj testiranje izvede zgolj na naslovu localhost:3000. Omenjeno nastavitev zahtevamo z dvojnim klikom v seznamu na levi strani Contexts → Default Context in nato Session. Pri vsaki izmed nastavitev Exclude from Proxy, Exclude from Scanner in Exclude from Spider dodamo regularni izraz, kjer zahtevamo omenjeno omejitev delovanja zgolj na lokalno okolje.

Rezultat uvoza OpenAPI specifikacije REST API strežnika in ročno dodanih spletnih naslovov je prikazan na sliki 4.1. V nadaljevanju bomo s pomočjo funkcionalnosti Manual Explore (glej sliko 4.1) demonstrirali uporabo naše aplikacije, da orodju OWASP ZAP še dodatno olajšamo analizo.

Slika 4.1: Začetni čarovnik za varnostno analizo aplikacije v orodju OWASP ZAP

Pri ročnem preiskovanju aplikacije je priporočljiv vklop funkcionalnosti HUD (angl. Heads Up Display), ki nam sproti prikazuje pomanjkljivosti aplikacije, ko se sprehajamo po posameznih delih. Kot je prikazano na sliki 4.2, lahko izvajamo usmerjene napade, ves čas pa imamo na voljo statistiko o težavah na obstoječi strani (orodna vrstica na levi strani strani) in na celotnem spletnem mestu (orodna vrstica na desni strani strani).

Slika 4.2: Funkcionalnost HUD v orodju OWASP ZAP

Ko končamo z ročno demonstracijo uporabe naše spletne aplikacije, lahko dodatno poženemo še naslednje teste:

Spider, ki se sprehodi po začetnih spletnih naslovih in poišče še morebitne preostale,
Ajax Spider ima podobno funkcionalnost kot Spider s to razliko, da zna slediti tudi povezavam, ki so dinamično opredeljene z jezikom JavaScript (npr. SPA aplikacija) in
Active Scan, ki na podlagi znanih pomanjkljivosti izvede aktivne napade.

Ko se varnostna analiza aplikacije izvede (lahko traja nekaj minut), se izkaže, da so v naši aplikaciji prisotna tveganja, predstavljena v nadaljevanju.

4.2.5 Odprava težav s HTTP odgovori

Najbolj enostavno lahko na začetku odpravimo identificirana nizka in srednja tveganja, povezana s pomanjkanjem določenih podatkov v glavi HTTP odgovora, in sicer:

Server Leaks Information via “X-Powered-By” HTTP Response Header Field(s),
X-Frame-Options Headers Not Set,
Cross Site Scripting Weakness in
X-Content-Type-Options Header Missing.

Spremembe je treba dodati v datoteko app.js, kjer je implementirana Express aplikacija, in sicer na začetku vzpostavitve strežnika, kot prikazuje naslednji izsek kode.

app.js

// Odprava varnostnih pomanjkljivosti
app.disable('x-powered-by');
app.use((req, res, next) => {
  res.header('X-Frame-Options', 'DENY');
  res.setHeader('X-XSS-Protection', '1; mode=block');
  res.setHeader('X-Content-Type-Options', 'nosniff');
  next();
});

4.2.6 Odprava težav z registracijo in prijavo

Pri registraciji in prijavi ne preverjamo pravilnosti elektronskega naslova, zato v tem primeru dodamo regularni izraz, ki poskrbi za ustrezno obliko vnesenega podatka elektronskega naslova.

api/controllers/authentication.js

const register = async (req, res) => {
  if (!req.body.name || !req.body.email || !req.body.password)
    return res.status(400).json({ message: "All fields required." });
  else if (!(/(?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:(2(5[0-5]|[0-4][0-9])|1[0-9][0-9]|[1-9]?[0-9]))\.){3}(?:(2(5[0-5]|[0-4][0-9])|1[0-9][0-9]|[1-9]?[0-9])|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])/.test(req.body.elektronskiNaslov)))
    return res.status(400).json({"sporočilo": "E-mail is not valid!"});
  const user = new User();
  user.name = req.body.name;
  user.email = req.body.email;
  user.setPassword(req.body.password);
  try {
    await user.save();
    res.status(200).json({ token: user.generateJwt() });
  } catch (err) {
    if (err.code === 11000)
      res.status(409).json({
        message: "User with given e-mail address already registered.",
      });
    else res.status(500).json({ message: err.message });
  }
};

api/controllers/avtentikacija.js

const login = (req, res) => {
  if (!req.body.email || !req.body.password)
    return res.status(400).json({ message: "All fields required." });
  else if (!(/(?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:(2(5[0-5]|[0-4][0-9])|1[0-9][0-9]|[1-9]?[0-9]))\.){3}(?:(2(5[0-5]|[0-4][0-9])|1[0-9][0-9]|[1-9]?[0-9])|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])/.test(req.body.elektronskiNaslov)))
    return res.status(400).json({"sporočilo": "E-mail is not valid!"});
  else
    passport.authenticate("local", (err, user, info) => {
      if (err) return res.status(500).json({ message: err.message });
      if (user) return res.status(200).json({ token: user.generateJwt() });
      else return res.status(401).json({ message: info.message });
    })(req, res);
};

angl. The Open Web application Security Project↩︎
angl. Broken Access Control↩︎
angl. Broken Authentication↩︎
angl. Cryptographic Failures↩︎
angl. Sensitive Data Exposure↩︎
angl. Injection↩︎
angl. XML External Entities↩︎
angl. Insecure Design↩︎
angl. Security Misconfiguration↩︎
angl. Vulnerable and Outdated Components↩︎
angl. Cross-Site Scripting↩︎
angl. Identification and Authorization Failures↩︎
angl. Cross-Site Request Forgery↩︎
angl. Insecure Deserialization↩︎
angl. Software and Data Integrity Failures↩︎
angl. Using Components with Known Vulnerabilities↩︎
angl. Security Logging and Monitoring Failures↩︎
angl. Unvalidated Redirects and Forwards↩︎
angl. Insufficient Logging & Monitoring↩︎
angl. Server-Side Request Forgery↩︎
angl. Incidence rate↩︎
angl. encryption at rest↩︎
angl. load balancer↩︎
angl. tokenization↩︎
angl. forward secrecy↩︎
angl. rainbow table↩︎
angl. interpreter↩︎
angl. sanitization↩︎
angl. whitelist↩︎
angl. DataBase Management System↩︎
angl. backdoor↩︎
angl. Internet of Things↩︎
angl. Multi-Factor Authentication↩︎
angl. Single-Sign On↩︎