Differences

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

--- second_order_sqli [2023/12/04 15:12] – 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 23: / Line 23: @@
 __**Primjer**__ - **Zadatak s Hacknite platforme** - **e-Trgovina Union**
-**TODO: ubaci opis zadatka ovdje**
+<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.
@@ Line 49: / Line 55: @@
 <code> aaa' or '1' = '1' – </code>
-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.
+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 sa kojom ćemo dohvatiti one podatke koji nas zanimaju.
+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//, sa poljima  //username//, //password// i //role//. Taj dio koda je vidljiv na slici 21.
+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:
@@ Line 85: / Line 91: @@
 {{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 sa korisničkim imenom //admin//.
+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 sa 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 crackstaion bazi i da je to hash vrijednost koja se dobiva hashiranjem vrijednosti //zlocinikazna// algoritmom //sha256//.
+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}}