Autor: Marko Meić-Sidić, Lead Software Developer, Devōt

Sigurnost je velika prijetnja tvrtkama koje nastoje isporučiti softver što je brže moguće. Uz postojeće sigurnosne ranjivosti aplikacijskog koda i sigurnosnih proboja, tvrtke i programeri moraju biti svjesni i mogućih sigurnosnih ranjivosti koje supermoćna kvantna računala predstavljaju za trenutno korištene kriptografije. Kako bismo osvijestili sigurnosne rizike, ključno je biti informiran o novim prijetnjama informatičkoj sigurnosti.

Problemi su razni: enkriptirani podaci se kradu, spremaju se za potencijalno dekriptiranje kvantnim računalima u budućnosti i tako dalje. Kako bi osigurali zaštitu osjetljivih podataka, programeri moraju prioritizirati primjenu modernih sigurnih praksi programiranja, kao i implementirati snažne enkripcije i autentifikacije u aplikacije.

Nitko ne voli curenje informacija

Možda možemo živjeti s činjenicom da se naši podaci koriste bez našeg pristanka, ali nitko od nas ne voli da ti podaci “iscure” u javnost na internetu bez našeg pristanka ili znanja. Iako mnoge tvrtke imaju visoke standarde sigurnosti i ulažu velike količine novca u zaštitu podataka svojih korisnika, curenje podataka je i dalje čest problem. Kao korisnici interneta, svi imamo privatne podatke koji su pohranjeni na raznim web stranicama i aplikacijama. Stoga je važno biti svjestan opasnosti od curenja podataka te uvijek provjeravati sigurnost web stranica i aplikacija koje koristimo.

OWASP Top 10 najkritičnijih ranjivosti

Kako bi se zaštitile od napada, tvrtke bi trebale slijediti preporuke i najbolje prakse u području web sigurnosti. Open Worldwide Application Security Project® (OWASP) neprofitna je organizacija koja se bavi poboljšanjem sigurnosti softvera. Među mnogim projektima, OWASP radi i na dokumentima kao “OWASP Top 10 najkritičnijih ranjivosti” koji se sastoje od širokog konsenzusa o najvećim sigurnosnim rizicima za web aplikacije. Cilj ovog dokumenta je podići svijesti programera i drugih stručnjaka u IT industriji o najvećim sigurnosnim rizicima te educirati ih o tome kako spriječiti nastajanje tih rizika. Izdvajamo pet najkritičnijih ranjivosti iz navedenih top 10:

• A01:2021-Broken Access Control 94% aplikacija su testirane na neki oblik neispravne kontrole pristupa, što je pokazalo da su 34 uobičajene slabosti neispravne kontrole pristupa imale više pojavljivanja u aplikacijama od bilo koje druge kategorije.
• A02:2021-Cryptographic Failures ranije poznat kao izlaganje osjetljivih podataka, što je bio opći simptom, a ne glavni uzrok. Ovdje je ponovni fokus na nedostacima povezanim s kriptografijom koji često dovode do izlaganja osjetljivih podataka ili ugrožavanja sigurnosti sustava.
• A03:2021-Injection 94% aplikacija testirano je na neki oblik injectiona, a 33 CWE-a ovdje kategorizirana imaju drugo mjesto po broju pojavljivanja u aplikacijama. Cross-site scripting sada također spada u ovu kategoriju.
• A04:2021-Insecure Design nova kategorija s fokusom na rizike povezane s nedostacima dizajna. Ako kao industrija doista želimo napraviti pomak u sigurnosti, to zahtijeva veću upotrebu modeliranja prijetnji, sigurnih design patterna i principa i referentnih arhitektura.
• A05:2021-Security Misconfiguration 90% aplikacija testirano je na neki oblik pogrešne sigurnosne konfiguracije. Povećanjem prijelaza na visoko konfigurabilan softver, nije nam čudno vidjeti da ova kategorija napreduje. Bivša kategorija za XML vanjske entitete (XXE) sada je dio ove kategorije.

Broken Access Control

Kontrola pristupa provodi mjere kojima korisnici ne mogu djelovati izvan predviđenih dopuštenja. Nedostaci obično dovode do neovlaštenog otkrivanja informacija, izmjene ili uništavanja svih podataka, ili pak obavljanja neke poslovne funkcije izvan korisničkih ograničenja.

• Uobičajene ranjivosti kontrole pristupa uključuju:
• Neodobren pristup određenim mogućnostima ili korisnicima
• Zaobilaženje provjera kontrole pristupa mijenjanjem URL-a
• Dopuštanje pregledavanja ili uređivanja tuđeg accounta izlaganjem jedinstvene reference na objekte
• API sigurnost s nedostajućim kontrolama pristupa
• Pogrešna konfiguracija CORS-a koja omogućuje pristup API-ju iz neovlaštenih ili nepouzdanih izvora (odnosno nedostatak whitelistinga)

Implementacija testova sigurnosti u unit testove dugoročna je investicija koja znači više ulaganja u svijest programera o sigurnosti. Osim što programeri tako bolje znaju kako testirati sigurnosne probleme, ovo može uvelike poboljšati ukupnu kvalitetu softvera te smanjiti broj ranjivosti u web aplikacijama.

Kriptografski nedostaci

Kod prijenosa informacija, osiguravamo li sigurnost koristeći zaštićene HTTPS protokole? Web stranice osigurane HTTPS sigurnom vezom osiguravaju posjetiteljima pouzdanost zbog enkripcije prijenosa podataka, što podrazumijeva teže praćenje korisnika i njegovih podataka. Osim praćenja korisnika, osigurava se i dobiveni sadržaj jer se radi o sigurnom komunikacijskom kanalu gdje se onemogućuje presretanje i modifikacija dobivenog sadržaja. Neki internet pretraživači, kao npr. Google Chrome, penaliziraju i posebno označavaju web stranice nezaštićene SSL/TLS certifikatima (koji se koriste za HTTPS protokole).

Za prijenos datoteka između korisnika, datoteke osiguravamo pomoću FTPS protokola. Originalno je FTP protokol omogućavao korisnicima prijenos datoteka bez ikakve enkripcije ili mjera zaštite. FTPS je nadograđeni FTP s dodanom sigurnosnom razinom Secure Socket Layer (SSL). Tamo se, slično kao i kod HTTPS protokola, uspostavlja sigurnosni komunikacijski kanal kroz koji prolaze sve informacije između korisnika i web stranice. Svi su podaci enkriptirani i samo SSL zaštićeni server može dekriptirati te podatke pomoću zajedničkog SSL ključa.

SQL Injection

Sigurnosni problem koji postoji više od 20 godina. Još uvijek je prisutan i u 2023. godini, kako to?

SQL napadi ubacivanjem uključuju napadače koji šalju nevažeće podatke aplikaciji kao SQL naredbe koje se izvršavaju u pozadini kako bi manipulirali podacima u bazi podataka. Napadači ubacuju SQL naredbe tamo gdje ih se ne očekuje, naprimjer, u polje za unos lozinke prilikom prijave na aplikaciju.

Zaštita od SQL napada ubacivanjem se može osigurati uz nekoliko načina, kao naprimjer:

• Sanitizacija podataka korisničkog unosa: aplikacija bi trebala osigurati eliminaciju svih znakova iz korisničkog unosa koji bi se mogli izvršiti kao SQL kod, naprimjer zagrade i dvotočke.
• Aplikacija bi trebala osigurati validaciju unosa i ograničiti broj i tip znakova koje je moguće unijeti.
• Preporučena opcija je korištenje sigurnog API sučelja, koji u potpunosti izbjegava korištenje tumača (interpretera), pruža parametrizirano sučelje ili koristi alate za relacijsko mapiranje objekata (ORM).

Neki od razloga zašto ovaj sigurnosni problem postoji još uvijek i u 2023. godini su:

• Nedostatak određene svijesti o sigurnosti kod programera
• Manjak automatiziranih učinkovitih metoda testiranja koje omogućuju precizno otkrivanje injectiona (npr. testovi bez lažno pozitivnih rezultata)
• Korištenje libraryja za pristup bazama podataka koje bi trebale osigurati siguran način za pristup( često se još uvijek može zloupotrijebiti, dok programeri dobivaju lažan osjećaj sigurnosti)

Na kraju, skoro svaka web aplikacija koristi neki oblik baze podataka te sama količina SQL baza podataka na internetu nudi određenu površinu za napad.

Od stručnjaka do korisnika

Svakako je potrebno slijediti preporuke i najbolje prakse u području web sigurnosti, poput onih koje predlaže OWASP.

Međutim, iako su preporuke i sigurnosni alati dostupni, napadači često iskorištavaju ranjivosti koje se pojavljuju i u libraryjima koje koristimo u razvoju aplikacija. Prije smo morali sve ručno programirati jer nije bilo pomoćnih libraryja u tako velikom broju kao danas. S druge strane, oni koji su postojali, često nisu odgovarali potrebama naših aplikacija. Stoga su programeri morali imati široko znanje kako bi sami programirali funkcionalnosti bez pomoći dodatnih libraryja.

S obzirom na to da se nismo mogli previše oslanjati na gotova rješenja, većina je programera pridavala više pozornosti upravo sigurnosti. Međutim, s vremenom smo počeli koristiti libraryje za gotovo sve, ali nismo zadržali želju razumjeti sve pojedinosti unutar tih libraryja. Napadači koji ciljaju naše aplikacije ili libraryje mogu koristiti tehnike koje iskorištavaju i najmanje probleme u našem kodu. Čak i ako napišete kod ispravno, u 99% slučajeva tih preostalih 1% može učiniti vašu aplikaciju jednako ranjivom kao i da uopće niste implementirali nikakvu zaštitu. U nastavku teksta pročitajte primjer jednog takvog napada putem popularnih open-source paketa.

Oštećeni NPM Libraryji

NPM (Node Package Manager) najkorišteniji je Node.js upravitelj paketa za JavaScript. Kroz NPM možemo instalirati i upravljati paketima naših JavaScript aplikacija. Korisnici popularnih open source paketa “colors” i “faker” ostali su zatečeni kada su vidjeli da im se aplikacije ruše i prikazuju besmislice, a radilo se o čak nekoliko tisuća aplikacija. Tvorac ovih paketa namjerno je uključio beskonačnu petlju koja je srušila stotine aplikacija koje se oslanjaju na te pakete. Petlje koje ispisuju besmislene ne-ASCII znakove na konzole svih aplikacija koje koriste te pakete nastavljale bi se beskonačno izvršavati te tako rušiti aplikacije. Stvarni razlog iza ovog postupka je bila odmazda protiv mega korporacija i komercijalnih korisnika open source projekata, koji se uvelike oslanjaju na besplatni softver kojima pridonose zajednice, dok navedeni nikako ne pridonose zajednici.

Neke od preporuka za programiranje i korištenje open source libraryja su:

• Paziti koje pakete koristimo
• Odabrati pakete koje održavaju osnovani konzorciji posvećeni poboljšanju i održavanju softvera
• Dati prednost korištenju izvornog koda od binarnog kada je god to moguće

Posljednja preporuka je važna jer binarne datoteke podrazumijevaju daleko veću razinu rizika jer na kraju nije moguće potvrditi da je uopće izgrađena pridruženim izvornim kodom. Najbolji način bi bio izravno koristiti izvorni kod, provjeriti integritet i analizirati ranjivost koda prije same upotrebe u razvoju aplikacije.

Vrhunski kod je siguran kod

Određenu razinu sigurnosti možemo osiguravati i korištenjem raznih alata za provjeru ranjivosti našeg koda, kao na primjer:

• OWASP ZAP, najpopularniji alat za testiranje sigurnosti web aplikacija
• MobSF, pruža automatizirano sigurnosno testiranje mobilnih aplikacija
• SonarQube, koji se koristi za analizu i testiranje kvalitete koda i sigurnosti aplikacija u raznim programskim jezicima

Navedeni alati mogu otkriti razne ranjivosti web i mobilnih aplikacija, koje uključuju: ugroženu autentifikaciju, izlaganje osjetljivih podataka, pogrešne sigurnosne konfiguracije, SQL napade ubacivanjem (SQL injection), cross-site skriptiranje, nesigurnu deserijalizaciju podataka, kao i komponente i libraryje s poznatim ranjivostima.

Kako tvrtke danas mogu zaštiti svoje podatke?

U današnje vrijeme, sigurnost nam je potrebnija nego prije 10 godina. Od HTTP anomalija, SQL injection napada i cross-site skriptiranja (XSS), pa do pokušaja preuzimanja računa i zlonamjernih robota. Kako bismo zajamčili sigurnost svojih aplikacija, ključno je da svaka tvrtka koja posluje na webu ne mijenja sigurnost nauštrb brzine isporuke novih aplikacija ili funkcionalnosti. I ono najvažnije – da tvrtka maksimalno osigura podatke svojih krajnjih korisnika.