Tehnika napada z injiciranjem SQL-stavkov izkorišča dejstvo, da je praktično vsaka spletna aplikacija povezana s spletno ali zaledno bazo podatkov in z njo komunicira. Napadalec pa želi spletno rešitev pretentati tako, da v različna vnosna polja vstavi prilagojene ukaze, s katerimi poskuša doseči, da mu bo aplikacija izpisala podatke, ki jih je z ukazom zahteval od podatkovne baze. S tem lahko napadalec precej elegantno in neposredno pride do podatkov, do katerih sicer ne bi mogel oziroma smel, in v nadaljevanju morebiti kakšne podatke tudi spremeni. To pa je očitno resna težava.
Povej mi vse, kar veš
Kako deluje napad z injiciranjem SQL-stavkov? Poglejmo si preprost primer. Aplikacija vsebuje podatke o različnih uporabnikih. Uporabnik lahko prek aplikacije dostopa do skritih podatkov o uporabniku, a le pod pogojem, da v aplikacijo vpiše ustrezno uporabniško ime in geslo.
Recimo, da so podatki, shranjeni v bazi podatkov, v naslednji obliki:
Ko se v aplikacijo prijavi uporabnik Bojan, vnese svoje geslo (Geslo1), aplikacija pa mu vrne vsebino polja »Skriti podatki123«. Logika delovanja aplikacije je taka, da od uporabnika najprej pridobi uporabniško ime in geslo, nato pa podatkovni bazi pošlje naslednji zahtevek:
Vrni mi vrednost polja »podatki« za vse ID-je, kjer je uporabnik=vpisan_uporabnik IN geslo=vpisano_geslo
Ta zahtevek podatkovni bazi ukaže, da v svoji tabeli primerja vpisane podatke oziroma vrne podatek »Skriti podatki« za vse vrstice, kjer se vpisano uporabniško ime IN geslo ujemata z zapisom v bazi.
Napadalec pa lahko s preprostim popravkom uporabniškega imena in gesla pretenta aplikacijo:
Vrni mi vrednost polja »podatki« za vse ID-je, kjer je uporabnik=blabla ALI 1=1 ALI a='IN geslo=' ALI blabla=1
Podatkovna baza tak ukaz zdaj razume drugače, kot si to predstavlja aplikacija. Del ukaza, kjer je bil prej izraz IN, je zdaj vstavljen med narekovaje, zato ga bo baza privzela kot vrednost parametra, ukaze ALI iz vpisanih parametrov pa bo privzela kot ločnico med posameznimi pogoji.
Rezultat? Baza se bo zdaj »sprehodila« po vseh uporabnikih in pri vsakem posebej preverila, ali so izpolnjeni pogoji za vračilo podatkov. Ker je napadalec podatke zvito vpisal tako, da bo drugi pogoj vedno izpolnjen in je med pogoji izraz ALI in ne več IN, bo baza aplikaciji vrnila vrednosti »Skriti podatki« vseh uporabnikov!
»Ključni vidik te ranljivosti je, da podatkovna baza drugače razume ukaze, kot pa si jih predstavlja aplikacija. Prav zato bi morali programerji spletnih aplikacij z ustreznimi mehanizmi ustrezno zavarovati svoje aplikacije pred napadi z injiciranjem SQL-stavkov. Gre za nekakšno osebno higieno v svetu programiranja,« pojasnjuje Vladimir Ban, strokovnjak za kibernetsko varnost v podjetju Smart Com, ki je napisal tudi belo knjigo Odkrivanje in preprečevanje SQL Injection.
Kompleksnost napadov vse večja, posledice pa hujše
V praksi so ranljivosti zaradi injiciranja SQL-stavkov bistveno bolj kompleksne, kot je zgoraj opisani primer. To v informacijske sisteme vnaša znatno večje grožnje, kot je (le) dostop do nekaterih podatkov. Ogroženi niso samo podatki, ki so neposredno povezani z ranljivo aplikacijo, ampak tudi podatki iz drugih aplikacij v podjetju, če so na istem strežniku (podatkovni bazi), podatki o skrbnikih (gesla, uporabniška imena, dostopi), ki se pogosto shranjujejo v isto bazo, in v luči sveže uredbe GDPR tudi podatki, ki veljajo za osebne/občutljive (na primer seznam e-poštnih naslovov uporabnikov, prijavljenih na e-novice, zbranih prek spletne strani).
»Poznamo ranljivosti, ki so sicer lahko zelo nevarne, a je dejanska zmožnost njihove izrabe odvisna od drugih okoliščin; nekatere so nekje polno izrabljive, druge delno, tretje sicer obstajajo, a jih ni možno izrabiti. Pri ranljivostih injiciranja SQL-stavkov žal velja prvo – ko se pojavijo, praksa kaže, da jih praviloma napadalec lahko izrabi v celoti, posledice pa so za podjetja lahko zelo hude,« razlaga Ban.
