Kako IT timovi mogu zaštiti medije od SQL napada

09.09.2021. / 08:47

Digitalni napadi su realnost. A ta realnost često biva prepoznata kroz napade na novinare/ke ili aktiviste/kinje. Zbog specifičnosti svog profesionalnog i aktivističkog angažmana, ulazeći u sfere poput korupcije, različitih političkih afera, nepotizma i nepravde, oni bivaju dodatno izloženi potencijalnim digitalnim, a nerijetko i fizičkim, napadima.

Sve češći napadi na novinare/ke dolaze kroz umetanje kodova. Napadi umetanjem koda su među najstarijim i najopasnijim napadima. Često sa sobom nose krađu i gubitak podataka, kompromitovanje integriteta informacija, uskraćivanje usluga na internetu, kao i potpune kontrole sistema. Veliki problem ovakvih napada jeste i činjenica da ih je teško prepoznati, jer korisnik/ca ne prepoznaje razliku spajanja na internet preko regularne ili lažne mreže.

Najčešći napadi umetanjem koda dolaze kroz SQL injection napade. SQL injection je napad u kojem se zlonamjerni kod ubacuje u SQL server kako bi izvršio određenu naredbu. Najčešći rezultat ovakvih napada jesu neautorizovani pristupi poverljivim podacima ili uništenje važnih podataka.

Web ranjivost je ogroman problem koji pogađa ne samo pojedince/ke, već i velike kompanije. Uzimajući to u obzir, medijske redakcije bivaju veoma izložene i pitanje imanja jakog IT tima, te programera/ki koji će se ozbiljno baviti kreiranjem zaštite postaje krucijalno.

Brian Vermeer, zagovarač razvoja u Snyku navodi neke od važnih načina koje programeri/ke mogu slijediti kako bi spriječili SQL napade. Ovi savjeti se najviše odnose na IT timove unutar redakcija, ali uveliko mogu olakšati svakodnevni posao novinara/ki, koji sa dobrom početnom zaštitom lakše mogu da se fokusiraju na svoj posao, a ne da konstantno brinu o potencijalnim digitalnim napadima. Naravno, individualna (digitalna) zaštita je i dalje važna i svaki novinar/ka mora dodatno obratiti pažnju na nju.

Pristup nutlog povjerenja

On prije svega navodi da programeri/ke trebaju osigurati da provjera unosa na strani klijenta/ice nije jedina linija obrane. Ova je potvrda izvrstan alat za poboljšano korisničko iskustvo, ali ne radi kao sigurnosni mehanizam. Programeri/ke bi trebali tretirati sve što klijent/ica pošalje kao potencijalno štetno i stoga bi trebali biti valjani na strani poslužitelja, idealno što bliže izvoru.

Dalje, važno je promisliti o privilegijama korisnika/ca baze podataka. Svi napadi ubrizgavanjem SQL-a su štetni, ali neki su štetniji od drugih: pristup informacijama o korisnicima jedno je, a mijenjanje ili brisanje drugo. Zbog toga je strateški pristup privilegijama pristupa bazama podataka veoma važan.

S druge strane, važno je imati više od jednog korisnika/cu baze podataka, jer stvaranje više korisnika/ca baze podataka i njihovo povezivanje sa određenim ulogama aplikacije sprječava napadača da brzo preuzme cijelu bazu podataka.

Parametri su najbolja odbrana

Mnogi jezici dolaze s ugrađenim značajkama koje sprječavaju ubrizgavanje SQL-a, pa pri pisanju SQL upita možete koristiti pripremljenu izjavu za sastavljanje parametara.

Pripremljeni izrazi ograničavaju SQL izraze koji se mogu unijeti: programer stvara osnovni upit s rezerviranim mjestima, a zatim se korisnički zadani parametri mogu sigurno pridružiti tim rezerviranim mjestima.

Parametrizacija je također najvažnija pri radu sa pohranjenim procedurama, jer i pohranjena procedura može biti ranjiva. Programeri/ke bi trebali parametrizirati upite u svojoj pohranjenoj proceduri, umjesto da spajaju parametre, kako bi se zaštitili od ubrizgavanja. Međutim, problem koji se stvara prilikom parametrizacije često jesu različiti jezici koje ne podržavaju pripremljene izraze ili starije baze podataka ne dopuštaju programerima/kama da unose korisnički unos kao parametre. U takvim slučajevima, najbolja alternativa jeste provjera unosa. Provjera unosa treba biti pažljiva i oslanjati se na dopušteni popis, pomoću dobro održavane biblioteke ili stvaranjem pravila koje opisuje sve dopuštene obrasce, na primjer, s regularnim izrazom. Naravno, čak i ako su dostupne pripremljene izjave, provjera unosa je neophodna.

Višeslojna sigurnost i stroga provjera

Uz parametrizaciju i provjeru ulaza, programeri/ke bi trebali razmisliti o korištenju sloja objektno-relacijskog mapiranja (ORM) za zaštitu od ubrizgavanja. Pretvaranjem baza podataka u objekte i obrnuto, smanjuju se eksplicitni SQL napadi. Ipak, ranjivosti su i dalje potencijalno prisutne, ako se koriste pogrešne ili zastarjele verzije Sequelize ili Hibernate, pa programeri/ke moraju biti na oprezu.

Na kraju, kakve god se sigurnosne strategije primjenjuju, važno je da postoji strog sistem pregleda kodova i prepoznavanja ranjivosti.  Za najviše razine sigurnosti, programeri/ke bi trebali potražiti posebno dizajnirane alate za skeniranje kako bi automatski provjerili ima li ranjivosti ubrizgavanja SQL -a i upozorili ih na sve slabosti u kodu.

Ovo su veoma važni koraci koje svaki IT tim unutar redakcija može da preduzme kako bi zaštitni zid od veoma ozbiljnih SQL napada bio što čvršći. Živimo u digitalnom svijetu u kom svakodnevno rastu digitalni napadi i zbog toga je još više važno da redakcije pojačaju IT timove kako bi zaštita novinara/ki, izvora informacija, ali i medija bila na što većem nivou.

Ocijenite kvalitet članka