Analiza Devōta: Sigurnost na Internetu u 2023. godini

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

Sigurnost je velika prijetnja tvrtki 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čke sigurnosti.

Problemi su različiti: šifrirani podaci se kradu, pripremaju se za potencijalno dešifriranje sa strane kvantnih računala u budućnosti, i tako dalje. Kako bi osigurali zaštitu osjetljivih podataka, programeri moraju dati prioritet primjeni modernih sigurnih programskih praksi, kao i implementirati jaku enkripciju i autentifikaciju u aplikacijama.

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 javnosti 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 najbolju praksu u području web sigurnosti. Open Worldwide Application Security Project® (OWASP) je neprofitna organizacija posvećena poboljšanju sigurnosti softvera. Među mnogim projektima, OWASP također radi na dokumentima poput “OWASP Top 10 Most Critical Vulnerabilities” koji se sastoji od širokog konsenzusa o najvećim sigurnosnim rizicima za web aplikacije. Cilj ovog dokumenta je podići svijest programera i drugih stručnjaka iz IT industrije o najvećim sigurnosnim rizicima te ih educirati kako spriječiti njihovu pojavu. Izdvajamo pet najkritičnijih ranjivosti iz navedenih top 10:

• A01:2021-Pokvarena kontrola pristupa 94% aplikacija testirano je na neki oblik neispravne kontrole pristupa, što se pokazalo da su 34 uobičajene slabosti neispravne kontrole pristupa imale više pojavljivanja u aplikacijama od bilo koje druge kategorije.
• A02:2021-Kriptografske greške ranije poznat kao izlaganje osjetljivih podataka, što je bio opći simptom, a ne glavni uzrok. Ovdje je ponovni fokus na nedostatke povezane s kriptografijom koji često dovode do izlaganja osjetljivih podataka ili ugrožavanja sigurnosti sustava.
• A03:2021-Injekcija 94% aplikacija testirano je na neki oblik injekcijaa 33 CWE-a ovdje kategorizirana imaju drugo mjesto po broju pojavljivanja u aplikacijama. Skriptiranje na više stranica sada također spada u ovu kategoriju.
• A04:2021-Nesiguran dizajn 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 uzorak dizajna te načela i referentne arhitekture.
• A05:2021-Sigurnosna pogrešna konfiguracija 90% aplikacija testirano je na neki oblik pogrešne sigurnosne konfiguracije. S porastom prijelaza na visoko konfigurabilni softver, ne iznenađuje nas što ova kategorija napreduje. Bivša kategorija za XML vanjske entitete (XXE) sada je dio ove kategorije.

Pokvarena kontrola pristupa

Kontrola pristupa provodi mjere kojima se korisnici ne mogu djelovati izvan predviđenih dopuštenja. Nedostaci obično dovode do neovlaštenog otkrivanja informacija, izmjena ili uništavanja svih podataka, ili pak pak nekih poslovnih funkcija izvan korisničkih ograničenja.

• Uobičajene ranjivosti kontrole pristupa uključuju:
• Neovlašteni pristup određenim značajkama ili korisnicima
• Zaobilaženje provjere kontrole pristupa mijenjanju 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 dopušta pristup API-ju iz neovlaštenih ili nepouzdanih izvora (tj. nedostatak bijela lista)

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

Kriptografske greške

Prilikom prijenosa informacija osiguravamo li sigurnost korištenjem sigurnih HTTPS protokola? Web stranice osigurane HTTPS sigurnim vezom posjetiteljima pružaju pouzdanost zbog enkripcije prijenosa podataka, što podrazumijeva otežano praćenje korisnika i njihovih podataka. Osim praćenja korisnika, osiguran je i primljeni sadržaj jer se radi o sigurnom komunikacijskom kanalu gdje je nemoguće presretanje i modificiranje primljenog sadržaja. Neki internet preglednici, kao npr. Google Chrome kažnjava i posebno označava web stranice koje nisu zaštićene SSL/TLS certifikatima (koji se koriste za HTTPS protokol).

Za prijenos datoteka između korisnika osiguravamo datoteke pomoću FTPS protokola. Izvorno je FTP protokol korisnicima dopuštao prijenos datoteka bez ikakve enkripcije ili sigurnosnih mjera. FTPS je nadograđen FTP s dodanim slojem sigurnosti Secure Socket Layer (SSL). Tu se, slično HTTPS protokolu, uspostavlja siguran komunikacijski kanal kojim prolaze sve informacije između korisnika i web stranica. Svi podaci su šifrirani i samo poslužitelj zaštićen SSL-om može te podatke dešifrirati pomoću zajedničkog SSL ključa.

SQL injekcija

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

Napadi SQL injekcijom uključuju napadače koji šalju nevažeće podatke aplikacije kao SQL naredbe koje se izvršavaju u pozadini radi manipuliranja podacima u bazi podataka. Napadači ubacuju SQL naredbe tamo gdje se ne očekuju, primjerice, u polje za unos lozinke prilikom prijave u aplikaciju.

Zaštita od napada SQL injekcijom može se osigurati na nekoliko načina, kao što su:

• Čišćenje podataka korisničkog unosa: aplikacija bi trebala osigurati uklanjanje svih znakova iz korisničkog unosa koji bi se mogli izvesti kao SQL kod, na primjer zagrada i dvotočaka.
• Aplikacija bi trebala osigurati provjeru valjanosti unosa i ograničiti broj i vrstu znakova koji se mogu 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 u 2023. godini su:

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

Uostalom, gotovo svaka web aplikacija koristi neki oblik baze podataka, a sama količina SQL baze podataka na Internetu nudi određenu površinu za napad.

Od stručnjaka do korisnika

Svakako je potrebno slijediti preporuke i najbolju praksu 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 iu knjižnicama koje koristimo u razvoju aplikacija. Prije smo sve morali programirati ručno jer nije bilo pomoćnika knjižnica u tako velikom broju kao danas. S druge strane, oni koji su postojali često nisu zadovoljavali potrebe naših aplikacija. Stoga su programeri morali imati veliko znanje kako bi sami programirali funkcionalnosti bez dodatne pomoći knjižnica.

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

Oštećeni NPM Knjižnice

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 otvoreni izvor paketi “colors” i “faker” ostali su zatečeni kada ste 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 konzoli svih aplikacija koje koriste te pakete nastavljale bi se beskonačno izvršavati te tako rušiti aplikacije. Stvarni razlog iza ovog postupka bio je protiv mega korporacija i komercijalnih korisnika open source projekata, koji se uvelike oslanjaju na besplatne softvere kojima se pridonosi zajednici, dok navedeni nikako ne pridonose zajednici.

Neke preporuke za programiranje i korištenje otvorenog koda knjižnica su:

• Paziti koje pakete koristimo
• Odaberite pakete koje održavaju uspostavljeni 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 iste upotrebe u razvoju aplikacije.

Vrhunski kod je siguran kod

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

• OWASP ZAP, najpopularniji alat za testiranje sigurnosti web aplikacije
• MobSF, pruža automatizirano sigurnosno testiranje mobilnih aplikacija
• SonarQube, koji se koristi za analizu i testiranje kvalitete koda i sigurnosne aplikacije na različitim programskim jezicima

Ovi alati mogu otkriti razne ranjivosti web i mobilnih aplikacija, uključujući: ugroženu autentifikaciju, izlaganje osjetljivih podataka, netočne sigurnosne konfiguracije, napade SQL injekcijom (SQL ubrizgavanje), cross-site skriptiranje, nesigurna deserijalizacija podataka, kao i komponente i u knjižnici s poznatim ranjivostima.

Kako danas tvrtka može zaštititi svoje podatke?

Danas nam je potrebna sigurnost prije više od 10 godina. Od HTTP anomalija, SQL ubrizgavanje napada i cross-site skriptiranja (XSS), pa do pokušaja preuzimanja računala 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.