Web aplikacije, zbog svoje otvorenosti prema globalnoj mreži, izložene su konstantnoj pretnji od strane korisnika koji, iz različitih motiva, pokušavaju da zaobiđu njihove sigurnosne mehanizme.
U ranim danima interneta, jedan od najčešćih napada bio je takozvani „brute force“ napad. Botovi, ili pojedinci sa mnogo slobodnog vremena, uporno su isprobavali hiljade kombinacija korisničkih imena i lozinki, sve dok ne bi pronašli onu koja im omogućava neovlašćeni pristup.
Danas, zahvaljujući politikama jačih lozinki, ograničenjima broja pokušaja prijava i primeni CAPTCHA sistema, „brute force“ napadi su znatno manje efikasni. Međutim, sajber kriminalci stalno razvijaju nove taktike. Ubrzo su otkrili da polja za unos teksta u web aplikacijama i stranicama mogu biti zloupotrebljena. Ubacivanjem neočekivanog teksta, mogu naterati aplikaciju da izvrši funkcije koje nisu bile predviđene, što je dovelo do pojave takozvanih „injection“ napada.
Ovi napadi se ne koriste samo za neovlašćeno prijavljivanje, već i za krađu privatnih i osetljivih informacija, pa čak i za preuzimanje kontrole nad celim serverom. Zbog toga, „injection“ napadi predstavljaju veliku opasnost ne samo za same web aplikacije, već i za korisnike čiji podaci se nalaze u tim aplikacijama, a u najgorim slučajevima, i za druge povezane aplikacije i servise.
Injekcija koda
Injekcija koda je jedna od najučestalijih vrsta „injection“ napada. Ako napadači poznaju programski jezik, framework, bazu podataka ili operativni sistem koji koristi web aplikacija, mogu da ubace štetan kod putem polja za unos teksta. Na ovaj način mogu naterati web server da izvrši radnje koje nisu predviđene originalnim dizajnom.
Ovakve vrste napada su moguće kod aplikacija koje nemaju adekvatnu validaciju ulaznih podataka. Kada polje za unos teksta omogućava korisnicima da unesu bilo šta, aplikacija postaje ranjiva. Da bi se sprečili ovakvi napadi, neophodno je ograničiti korisnički unos koliko god je to moguće.
Na primer, potrebno je ograničiti očekivanu količinu podataka, proveravati format unesenih podataka pre nego što se prihvate, kao i ograničiti skup dozvoljenih karaktera.
Ranjivosti za injekciju koda se mogu otkriti relativno lako, jednostavnim testiranjem polja za unos teksta različitim vrstama sadržaja. Iako ih je lako pronaći, za napadača može biti teže da ih iskoristi, ali kada to uspe, posledice mogu uključivati gubitak poverljivosti, integriteta, dostupnosti ili funkcionalnosti same aplikacije.
SQL Injekcija
SQL injekcija funkcioniše na sličan način kao injekcija koda. Napadač ubacuje SQL skriptu – jezik koji koristi većina baza podataka za izvođenje upita – u polje za unos teksta. Skripta se zatim šalje aplikaciji, koja je direktno izvršava u svojoj bazi podataka. Ovo može omogućiti napadaču da zaobiđe ekran za prijavu, ili da izvrši mnogo ozbiljnije radnje, kao što je čitanje osetljivih podataka direktno iz baze, njihova modifikacija ili brisanje, ili čak izvršavanje administrativnih operacija nad bazom.
PHP i ASP aplikacije su posebno podložne SQL injekcijama zbog svojih starijih funkcionalnih interfejsa. J2EE i ASP.Net aplikacije su obično bolje zaštićene od ovih napada. Kada se otkrije SQL injekcijska ranjivost – što je često relativno lako – potencijalna šteta je ograničena samo veštinom i kreativnošću napadača. Dakle, uticaj SQL injekcije može biti izuzetno ozbiljan.
Komandna Injekcija
Ovi napadi su takođe često posledica nedovoljne validacije ulaza. Razlikuju se od injekcije koda po tome što napadač ubacuje sistemske komande umesto delova koda ili skripti. Na ovaj način, napadač ne mora da zna programski jezik na kome je aplikacija zasnovana, niti jezik baze podataka. Međutim, mora da poznaje operativni sistem koji koristi hosting server.
Ubačene sistemske komande izvršava operativni sistem servera, sa privilegijama koje ima aplikacija. To može dovesti do izlaganja sadržaja datoteka na serveru, otkrivanja strukture direktorijuma, promene korisničkih lozinki, između ostalog.
Ove napade može sprečiti sistemski administrator ograničavanjem nivoa pristupa koji imaju web aplikacije na serveru.
Cross-site Scripting (XSS)
Kada god aplikacija ubacuje korisnički unos u izlaz koji generiše, bez validacije ili kodiranja, pruža se prilika napadaču da pošalje zlonamerni kod drugom korisniku. Cross-site scripting (XSS) napadi koriste ove mogućnosti za ubacivanje malicioznih skripti u pouzdane web lokacije, koje se zatim šalju drugim korisnicima aplikacije, koji postaju žrtve napada.
Pretraživač žrtve će izvršiti malicioznu skriptu, ne znajući da joj se ne može verovati. Prema tome, pretraživač će joj omogućiti pristup tokenima sesije, kolačićima ili osetljivim informacijama koje pretraživač čuva. Ako su ispravno programirane, skripte mogu čak i prepisati sadržaj HTML datoteke.
XSS napadi se obično dele u dve glavne kategorije: sačuvani i reflektovani.
Kod sačuvanih XSS napada, zlonamerna skripta se trajno čuva na ciljnom serveru, na primer u forumu za poruke, u bazi podataka, ili u dnevniku posetilaca. Žrtva je dobija kada njen pretraživač zatraži sačuvane informacije. Kod reflektovanih XSS napada, zlonamerna skripta se „reflektuje“ u odgovoru servera, koji uključuje ulaz koji je poslat serveru. To može biti poruka o grešci ili rezultat pretrage, na primer.
XPath Injekcija
Ova vrsta napada je moguća kada web aplikacija koristi informacije koje je korisnik dostavio da generiše XPath upit za XML podatke. Način na koji ovi napadi funkcionišu je sličan SQL injekciji: napadači šalju neispravne informacije kako bi saznali strukturu XML podataka, a zatim ponovo napadaju kako bi pristupili tim podacima.
XPath je standardni jezik pomoću kojeg, slično kao kod SQL-a, možete definisati atribute koje želite da pronađete. Web aplikacije koriste korisnički unos kako bi postavile šablon za pronalaženje podataka u XML dokumentima. Slanjem nepravilnog unosa, šablon se može pretvoriti u operaciju koju napadač želi da primeni na podatke.
Za razliku od SQL-a, u XPath-u ne postoje različite verzije. To znači da se XPath injekcija može izvršiti na bilo kojoj web aplikaciji koja koristi XML podatke, bez obzira na njenu implementaciju. To takođe znači da se napad može automatizovati, pa za razliku od SQL injekcije, ima potencijal da se aktivira protiv neograničenog broja ciljeva.
Injekcija Komande Pošte
Ova metoda napada se koristi za zloupotrebu mail servera i aplikacija koje generišu IMAP ili SMTP izjave koristeći nevalidiran korisnički unos. IMAP i SMTP serveri ponekad nemaju jaku zaštitu od napada kao većina web servera, pa su zato lakše mete. Ulaskom preko mail servera, napadači mogu zaobići ograničenja kao što su CAPTCHA, ograničen broj zahteva itd.
Da bi zloupotrebili SMTP server, napadačima je potreban validan nalog e-pošte za slanje poruka sa ubacivanjem komandi. Ako je server ranjiv, on će odgovoriti na zahteve napadača, dozvoljavajući im, na primer, da zaobiđu ograničenja servera i koriste njegove resurse za slanje neželjene pošte.
IMAP injekcija se najčešće koristi kod web aplikacija za čitanje pošte, zloupotrebljavajući funkcionalnost čitanja poruka. U tim slučajevima, napad se može izvesti jednostavnim unošenjem URL adrese sa ubacenim komandama u adresnu liniju web pretraživača.
CRLF Injekcija
Ubrizgavanje karaktera za prelazak u novi red i povratak na početak reda (carriage return i line feed), poznato kao CRLF, u polja za unos web formulara, predstavlja metodu napada pod nazivom CRLF injekcija. Ovi nevidljivi karakteri označavaju kraj reda ili kraj komande u mnogim tradicionalnim internet protokolima, kao što su HTTP, MIME ili NNTP.
Na primer, ubacivanje CRLF u HTTP zahtev, praćeno određenim HTML kodom, može omogućiti slanje prilagođenih web stranica posetiocima web stranice.
Ovaj napad je moguć kod ranjivih web aplikacija koje ne primenjuju adekvatno filtriranje korisničkog unosa. Ova ranjivost otvara vrata drugim vrstama injekcijskih napada, kao što su XSS i ubacivanje koda, a može dovesti i do preuzimanja web stranice.
Injekcija Zaglavlja Host
Na serverima koji hostuju više web stranica ili aplikacija, zaglavlje hosta je neophodno da bi se odredilo koja od aplikacija (tzv. virtuelni host) treba da obradi dolazni zahtev. Vrednost zaglavlja govori serveru kojem virtuelnom hostu treba da pošalje zahtev. Kada server primi nevažeće zaglavlje hosta, obično ga prosleđuje prvom virtuelnom hostu na listi. To predstavlja ranjivost koju napadači mogu iskoristiti za slanje proizvoljnih zaglavlja hosta prvom virtuelnom hostu na serveru.
Manipulacija zaglavljem hosta se uglavnom odnosi na PHP aplikacije, mada se može primeniti i na drugim web tehnologijama. Napadi sa zaglavljem hosta se obično koriste kao okidači za druge vrste napada, kao što je trovanje web keša. Njegove posledice mogu uključivati izvršavanje osetljivih operacija od strane napadača, kao što je resetovanje lozinke.
LDAP Injekcija
LDAP je protokol dizajniran da olakša pretragu resursa (uređaja, datoteka, drugih korisnika) u mreži. Veoma je koristan za intranete, a koristi se i kao deo sistema za jedinstvenu prijavu za čuvanje korisničkih imena i lozinki. LDAP upiti koriste kontrolne karaktere koji utiču na njegovo ponašanje. Napadači mogu potencijalno da izmene planirano ponašanje LDAP upita ubacivanjem kontrolnih karaktera.
Kao i kod ostalih „injection“ napada, osnovni problem je neadekvatna validacija korisničkog unosa. Ako se tekst koji korisnik šalje aplikaciji koristi kao deo LDAP upita bez provere i „čišćenja“, upit može otkriti listu svih korisnika jednostavnim korištenjem zvezdice na odgovarajućem mestu unutar ulaznog niza.
Sprečavanje „injection“ napada
Kao što smo videli u ovom članku, svi „injection“ napadi ciljaju servere i aplikacije koje su otvorene za sve korisnike interneta. Odgovornost za sprečavanje ovih napada leži na programerima aplikacija i administratorima servera.
Programeri aplikacija moraju biti svesni rizika koji proizlaze iz neadekvatne validacije korisničkog unosa, i moraju usvojiti najbolje prakse za „čišćenje“ ulaznih podataka, kako bi sprečili potencijalne rizike. Administratori servera moraju redovno vršiti reviziju svojih sistema, kako bi otkrili i popravili ranjivosti što je pre moguće. Postoji mnogo različitih opcija za sprovođenje ovih revizija, ručno ili automatski.