Hacknite Wiki

Second order SQL injection je podskup SQL injection ranjivosti, koji je kompliciraniji za izvršiti, ali je i razvojnim programerima teže detektirati takvu ranjivost . Razlika je što obični (first order) SQL injection je prisutan u slučajevima kada se korisnički unos, koji se odmah izvršava unutar nekog SQL upita, nije dobro sanitiziran i osiguran, dok second order SQL injection se izvršava tako da se neki korisnički unos prvo pohrani negdje na server ili u bazu podataka, a zatim se pozivanjem neke druge funkcionalnosti, koja koristi taj pohranjeni korisnički unos izvršava SQL injection.

Jednostavan primjer bi bio aplikacija, gdje je forma za registraciju korisnika zaštićena od SQL injectiona tako što dobro interpretira unos korisnika kao string i ne može se „escape-ati“ pomoću posebnih znakova, te bi korisnik pokušajem registracijom gdje unosi vrijednost

" user' or 'a' = 'a' — " 

u polje imena novog korisnika, samo stvorio novog korisnika kojemu bi username bio

" user' or 'a' = 'a' —  "

, ali kada bi taj korisnik koristio funkcionalnost promjene lozinke, gdje se pri promjeni lozinke koristi SQL upit u koji se ubacuje korisničko ime korisnika kojemu se mijenja lozinka, ako kod nije ispravno zaštićen, izvršio bi seSQL injection unutar SQL koda u kojemu bi se trebalo odabranom korisniku promijeniti lozinku.

Primjer nezaštićenog koda za izmjenu lozinke bio:

 
"UPDATE users SET password=" + novi_password + "WHERE username=" + korisnicko_ime "and password=" + stari password

(pretpostavka je da je korisnikov unos novog passworda također dobro filtriran)

Pri pokretanju ovog koda za prethodno registriranog korisnika s unosom novog passworda „moj_novi_password23“, kod koji bi se izvršio bi bio:

UPDATE users SET password= ’moj_novi_password23’  WHERE username=  ’user' or 'a' = 'a' — ’ and password= 'stari_password'

No, uzimajući u obzir da je </code>—</code> jednako komentaru, prethodan kod jest ekvivalentan sljedećem:

UPDATE users SET password= ’moj_novi_password23’  WHERE username=  ’user' or 'a' = 'a'

, čime bi se svim korisnicima password promijenio u

moj_novi_password23

.

Primjer - Zadatak s Hacknite platforme - e-Trgovina Union

TODO: ubaci opis zadatka ovdje

Pri rješavanju zadatka, prvo što nam se nudi je forma za registraciju.

TODO: slika ovdje

Analizom izvornog koda ovog zadatka, koji je također dostupan u zadatku, vidimo da se SQL upit tako formiran da se nad njime ne mogu izvršavati SQL injekcije, što je prikazano u slici ispod.

TODO: slika ovdje

Naime, kod koristi tzv. parametrizirane upite koji onemogućavaju SQL injekciju.

Analizom ostalih dijelova koda, može se vidjeti da se parametrizirani upiti koriste na svim mjestima, osim u funkciji sadrzaj(), unutar user.php datoteke.

TODO: slika ovdje

Ovdje vidimo da se parametar

$_SESSION["user"]

ne ubacuje u SQL upit na sigurni način, odnosno da postoji ranjivost. No parametar

$_SESSION["user"]

se već nalazi unutar sustava, taj parametar odgovara korisničkom imenu s kojim smo se registrirali.

Način na koji možemo iskoristiti ovu ranjivost jest da napravimo račun s korisničkim imenom koje će iskoristiti ranjivost unutar ovog SQL izraza, kada će nam sustav prikazivati sadržaj naše povijesti.

Kada napravimo korisnički račun s normalnim korisničkim imenom i prijavimo se u sustav, na početnoj stranici, tablica koja prikazuje povijest proizvoda je prazna.

Kao prvi pokušaj iskorištavanja ranjivosti možemo probati napraviti korisnički račun kojemu će korisničko ime biti

 aaa' or '1' = '1' – 

Nakon stvaranja korisničkog računa sa ovim korisničkim imenom, vidimo da se sada unutar tablice povijesti proizvoda nalaze proizvodi svih ostalih korisnika u sustavu, kao što je prikazano na slici ispod.

TODO: slika ovdje

Ovo znači da smo uspjeli izvršiti SQL injekciju nad sustavom i da sada znamo iskoristiti ranjivost. Sada još samo moramo pronaći način kako napraviti SQL injekciju sa kojom ćemo dohvatiti one podatke koji nas zanimaju.

Iz koda znamo da u bazi postoji tablica users, sa poljima username, password i role. Taj dio koda je vidljiv na slici 21.

Sada možemo pokušati izvršiti SQL injection, gdje će korisničko ime biti:

 aaaa' UNION SELECT username, password FROM users – 

Kako bismo dohvatili imena i passworde korisnika iz baze. Izvršavanjem ove SQL injekcije, dobivamo error koji je prikazan na slici ispod.