Ovaj stari ali dobar napad može da ošteti vaše veb aplikacije
SQL injekcioni napadi su dobro razumljivi i lako se mogu sprečiti, a prioritet za ublažavanje rizika treba u prvom redu da bude sprečavanje napada SQL injekcijom. Slušajte junaka crtanog filma i pročistite ulazne podatke za baze podataka. SQL injekcija, ili SQLi, je jedan od najmanje sofisticiranih bezbednosnih napada na veb aplikacije koje mogu dati protivniku potpunu kontrolu nad bazom podataka vaše veb aplikacije. Ovekovečen u crtanom filmu „Little Bobby Drop Tables“ u XKCD 327, SQLi je prvi put otkriven 1998. godine, ali i dalje nastavlja da dodijava veb aplikacijama preko interneta. Čak i OWASP Top Ten navodi injekciju kao pretnju za bezbednost veb aplikacija.
Dobre vesti? SQL injekcija je najniža od svih niskih voćki kako za napadače tako i za branioce. SQLi nije neka najsavremenija NSA Shadow Brokers oprema, tako je jednostavan da to može da uradi dete od tri godine. To je skript na dečjem nivou, tako da je popravljanje vaše veb aplikacije za ublažavanje rizika od SQLi-a tako lako da propuštanje da to učinite sve više liči na veliki nemar.
Definicija i vrste SQL injekcija
Postoji nekoliko vrsta SQL injekcija, ali sve one uključuju napadača koji ubacuje proizvoljni SQL u upit za bazu podataka veb aplikacije. Najjednostavniji oblik ubrizgavanja SQL-a je putem korisničkog unosa. Veb aplikacije obično prihvataju korisnički unos putem formulara, a čeoni program prosleđuje korisnički unos u bazu podataka za obradu. Ako veb aplikacija ne uspe da pročisti korisnički unos, napadač može da ubaci kakav god želi SQL u pozadinsku bazu podataka, pa zatim briše, kopira ili menja sadržaj baze podataka.
Napadač takođe može da izmeni kolačiće tako da otruju upit u bazu podataka veb aplikacije. Kolačići lokalno čuvaju podatke o stanju klijenta, a veb aplikacije obično učitavaju kolačiće i obrađuju te informacije. Zlonamerni korisnik ili zlonameran softver može da menja kolačiće tako da oni ubace SQL u pozadinsku bazu podataka.
Serverske promenljive, kao što su HTTP zaglavlja, takođe se mogu koristiti kao vektor SQL injektorskog napada. Falsifikovana zaglavlja koja sadrže proizvoljan SQL mogu da ubace taj kôd u bazu podataka ako veb aplikacija ne uspe da pročisti i te ulaze.
Napadi SQL injektiranja drugog reda su najsnažniji od svih, jer nisu dizajnirani da se pokrenu odmah, nego mnogo kasnije. Programer koji ispravno pročisti sve svoje unose protiv neposrednog napada i dalje može biti osetljiv na SQLi drugog reda kada se zatrovani podaci koriste u drugačijem kontekstu.
Kako se vrši SQL injekcija?
SQL injekcija, kao tehnika, starija je od mnogih ljudi koji danas koriste SQLi. SQLi napadi su rudimentarni i već dugo su automatizovani. Alati kao što su SQLninja, SQLmap i Havij olakšavaju testiranje sopstvenih veb aplikacija, ali i olakšavaju posao napadačima. Pre deset godina, crv SQLi je harao preko interneta. Da se vratimo u sadašnjost: malo se toga promenilo. Uprkos široko rasprostranjenoj svesti o SQL injekciji kao problemu, veliki procenat veb aplikacija ostaje ranjiv.
Automatski alati za testiranje mogu vam omogućiti da budete na korak ispred napadača koji traže lak put do plaćanja. Testiranje neprobojnosti vaših veb aplikacija pomoću alatke kao što je SQLmap je brz način da vidite da li su vaše zaštite adekvatne. SQLmap podržava praktično svaku glavnu bazu podataka koja se danas koristi i može da otkrije i iskoristi najpoznatije ranjivosti SQL injekcija. Pročistite svoj unos, ali testirajte da biste potvrdili da su vaše zaštite uspešne. Korisni podsetnik: Plavi tim i crveni tim su dve strane istog novčića.
Primer napada SQL injekcijom
Hajde da pogledamo osnovni SQL injekcioni napad. Pretpostavimo da ste napravili veb aplikaciju koja omogućava korisnicima da unesu svoj korisnički ID i preuzmu svoje korisničke profile. Čeoni deo veb aplikacije prosleđuje uneti korisnički identitet klijenta u pozadinsku bazu podataka. Baza podataka pokreće SQL upit i vraća rezultate u veb aplikaciju, koja prikazuje rezultate krajnjem korisniku.
Pozadinski upit za bazu podataka bi mogao da izgleda ovako:
SELECT *
FROM customers
WHERE customer_id = ‘1234567’
Pretpostavimo da u polje veb obrasca korisnik unese sledeći customer_id:
1234567; DELETE * customers WHERE ‘1’ = ‘1
Pozadinska baza podataka bi onda poslušno izvršila sledeći SQL:
SELECT *
FROM customers
WHERE customer_id = ‘1234567’;
DELETE *
FROM customers
WHERE ‘x’ = ‘x’
Zapamtite, baze podataka će veselo izvršavati više SQL izraza u nizu ako su razdvojeni tačkom i zarezom. Propuštanje da se u čišćenju korisničkog unosa uoči neupareni znak navoda „‘ “ omogućuje napadaču da obriše celu tabelu. Nadam se da ste imali dobre rezervne kopije. Jel’ tako? Jel’ tako…?
Ovo je bio namerno jednostavan primer, a postoji mnogo različitih vektora napada SQLi-a, koji svi rade na istom principu: propust veb aplikacije u čišćenju dovodi do izvršavanja udaljenog SQL koda.
Može li se otkriti SQL injekcija?
Sprečavanje napada SQL injekcijom nije teško, ali čak i najpametniji i najdobronamerniji programeri i dalje prave greške. Otkrivanje je stoga važna komponenta ublažavanja rizika od napada SQL injekcijom. Mrežna barijera (WAF – Web firewall) veb aplikacije može otkriti i blokirati osnovne napade SQL injekcijom, ali se ne treba oslanjati na to kao jedinu preventivnu meru.
Sistemi za otkrivanje upada (IDS), kako na mreži tako i na domaćinima, mogu se podesiti da otkrivaju napade SQL injekcijom. IDS zasnovan na mreži može da nadgleda sve veze sa serverom baze podataka i da označi sumnjivu aktivnost. IDS zasnovan na domaćinu može da prati dnevnike veb servera i upozorava kada se dogodi nešto čudno.
Ipak, napadi SQL injekcijom su dobro razumljivi i lako se mogu sprečiti, a prioritet za ublažavanje rizika treba pre svega da bude sprečavanje napada SQL injekcijom.
Kako sprečiti SQL injekcije
Poslušajte crtani Little Bobby Tables i očistite ulazne podatke za bazu podataka. Svaki unos u bazu podataka vaše veb aplikacije treba smatrati nepouzdanim i postupati prema tome. I slušajte dobre ljude iz OWASP-a kada vam kažu: „Pomalo je sramotno da postoji toliko uspešnih napada SQL injekcijom, jer je KRAJNJE jednostavno u vašem kodu izbeći ranjivost od SQL injekcije.“
OWASP-ov list za izbegavanje SQL injekcija ulazi u temu dublje nego što smo mi mogli ovde, ali OWASP nam kaže da sprečavanje napada SQL injekcijom zahteva od programera da validiranje ulaza stave na belu listu (ne na crnu listu), da koriste pripremljene iskaze sa parametrizovanim upitima, i da obuhvate iskočnom sekvencom sav ulaz dobijen od korisnika.
Ograničite i privilegije naloga. Pretpostavite da postoji kršenje. Šta ako programer propusti da pročisti jedino polje za unos korisničkog imena? Hej, desiće se. Programeri su samo ljudi. Pročistite unos, ali pretpostavite da će nešto proći mimo vas. Ograničite privilegije naloga korisnika baze podataka. Da li je, na primer, vaša veb aplikacija samo za čitanje? Da li su onda potrebne privilegije DROP TABLES? Verovatno ne. Ovde se primenjuje princip minimuma privilegija. Dajte veb aplikaciji minimalne privilegije koje su joj potrebne za rad.
Sačuvane procedure takođe mogu da otežaju ako ne i da onemoguće SQLi. Ako je vašoj veb aplikaciji potrebno da izvrši samo nekoliko SQL upita, kreirajte sačuvane procedure za izvršavanje tih upita. Tipično, samo administrator baze podataka ima privilegije za kreiranje ili menjanje uskladištenih procedura. Međutim, budite svesni toga da se mnoge baze podataka isporučuju sa podrazumevanim sačuvanim procedurama iz paketa, a napadači to znaju. Razmislite o uklanjanju tih podrazumevanih sačuvanih procedura, osim ako vam nisu zaista potrebne.
Sprečavanje SQL injekcija je minimalna neophodna pažnja
SQL injekcija je najniže od najnižih plodova veb aplikacija. Ovaj dobro poznati vektor napada lako eksploatišu neiskusni napadači, ali se lako sprečava uz malu količinu potrebne pažnje. 2018. godine više nema opravdanja da bilo koja veb aplikacija bude osetljiva na SQL injekcije. To je ono što izgleda minimalna pažnja za bezbednost veb aplikacija.
Izvor: CSO