Differences

This shows you the differences between two versions of the page.

--- second_order_sqli [2023/12/04 14:08] – lss
+++ second_order_sqli [2025/12/01 11:40] (current) – external edit 127.0.0.1
@@ Line 3: / Line 3: @@
 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  <code>" user' or 'a' = 'a' — " </code>u polje imena novog korisnika, samo stvorio novog korisnika kojemu bi username bio <code>" user' or 'a' = 'a' —  "</code> , 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.
+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  <code>" user' or 'a' = 'a' — " </code>u polje imena novog korisnika, samo stvorio novog korisnika kojemu bi username bio <code>" user' or 'a' = 'a' —  "</code> , 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 se SQL injection unutar SQL koda u kojemu bi se trebalo odabranom korisniku promijeniti lozinku.
 Primjer nezaštićenog koda za izmjenu lozinke bio:
@@ Line 20: / Line 20: @@
 <code>UPDATE users SET password= ’moj_novi_password23’  WHERE username=  ’user' or 'a' = 'a'</code>, čime bi se svim korisnicima password promijenio u <code>moj_novi_password23</code>.
+__**Primjer**__ - **Zadatak s Hacknite platforme** - **e-Trgovina Union**
+<file>
+Lokalna trgovina je odlučila napraviti svoju web stranicu na kojoj kupci mogu pratiti svoju povijest kupovine. Korisnici se mogu sami registrirati na tu stranicu, i pri svakoj fizičkoj kupnji u trgovini mogu dati svoje korisničko ime kako bi se njihova povijest kupovine unijela u bazu podatka. Stranica bi mogla biti korisna svim sadašnjim i budućim kupcima trgovine!
+Flag je u formatu CTF2021[brojevi]
+http://chal.platforma.hacknite.hr:10010
+</file>
+Pri rješavanju zadatka, prvo što nam se nudi je forma za registraciju.
+{{second_order_1.png}}
+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.
+{{second_order_2.png}}
+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.
+{{second_order_3.png}}
+Ovdje vidimo da se parametar <code>$_SESSION["user"]</code> ne ubacuje u SQL upit na sigurni način, odnosno da postoji ranjivost. No parametar <code>$_SESSION["user"]</code> 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
+<code> aaa' or '1' = '1' – </code>
+Nakon stvaranja korisničkog računa s 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.
+{{second_order_4.png}}
+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 s kojom ćemo dohvatiti one podatke koji nas zanimaju.
+Iz koda znamo da u bazi postoji tablica //users//, s 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:
+<code> aaaa' UNION SELECT username, password FROM users – </code>
+Kako bismo dohvatili imena i lozinka korisnika iz baze. Izvršavanjem ove SQL injekcije, dobivamo error koji je prikazan na slici ispod.
+{{second_order_5.png}}
+Ovaj error nam govori da broj parametara u SELECT izrazu koji smo konstruirali ne odgovara broju parametara u SELECT izrazu s kojim radimo UNION.
+Iz koda znamo da izraz odgovara sljedećem:
+SELECT * FROM povijest WHERE korisnik= '  aaaa' UNION SELECT username,password FROM users  --
+Iako se u tablici za prikaz proizvoda na početnoj stranici nalaze samo dva stupca, SQL izraz kojeg mi manipuliramo, iz kojega se naknadno prikazuju ta dva stupca na stranici ima više od dva stupca, no ne možemo točno znati koliko, budući da u djelu koda „ SELECT * FROM povijest “, jedino znamo da se dohvaćaju svi stupci iz tablice povijest, ali ne znamo točno koliko
+U sljedećem pokušaju možemo probati izvršiti SQL injection, gdje ćemo imati koristiti tri stupca u SELECT izrazu. Primjer takvog pokušaja jest stvaranje korisničkog računa s korisničkim imenom:
+<code> aaaa' UNION SELECT username,password,password FROM users – </code>
+{{second_order_6.png}}
+Vidimo da smo uspješno dobili hasheve lozinki svih korisnika u sustavu. Također vidimo da se na stranici prikazuje samo zadnji parametar koji smo unijeli u našem SELECT izrazu, koji je u ovom slučaju password. Ako želimo prikazati više informacija, možemo koristiti SQL-ov operator konkatenacije:  „  ||  “, da bi prikazali više vrijednosti u jednom stupcu, na primjer da bi prikazali username i password odvojene znakom dvotočke, za zadnji parametar trebamo umjesto samo password, unijeti „ username|| ': '||password “, koristeći ovu vrijednost za zadnji parametar, finalno korisničko ime kojim ćemo izvršiti SQL injection koji nam treba jest:
+<code>aaaa' UNION SELECT username,password, username|| ': '||password FROM users --</code>
+{{second_order_7.png}}
+Sada smo uspješno izvršili SQL injection pomoću kojega smo dohvatili i prikazali korisnička imena i hasheve lozinka svih korisnika u sustavu, Možemo vidjeti da su korisnici korisnički računi koje smo stvarali za izvršavanje SQL injekcija, te da jest zadnji korisnik, korisnik s korisničkim imenom //admin//.
+Kako bi dobili njegovu lozinku, odnosno „revers“ hasha njegove lozinke, možemo iskoristiti crackstation.net, veliku bazu podataka s parovima tekstualnih vrijednosti i njihovih već izračunatih hash vrijednosti u raznim algoritmima. Unosom administratovog hash-a lozinke u crackstation, dobivamo informaciju, da se ta hash vrijednost već nalazi u crackstation bazi i da je to hash vrijednost koja se dobiva hashiranjem vrijednosti //zlocinikazna// algoritmom //sha256//.
+{{second_order_8.png}}
+Sada prijavom u sustav s korisničkim imenom //admin// i lozinkom //zlocinikazna//, dobivamo flag koji je rješenje zadatka.