Differences

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

--- blind_sqli [2025/12/01 11:40] – external edit 127.0.0.1
+++ blind_sqli [2026/06/18 14:47] (current) – mbunic
@@ Line 1: / Line 1: @@
 ====Blind SQL injection====
-Pri općenitom testiranju ranjivosti nekog unosa na SQL injekcije, mogu se prvo pokušati unijeti jednostruki ili dvostruki navodnici i ako je web poslužitelj podešen da prosljeđuje pogreške korisniku, korisniku se može proslijediti i prikazati poruku greška koju je baza poslala, gdje na primjer piše da je neispravno korištenje znakova navodnika. U nekim situacijama sustav je podešen tako da se poruke pogreške iz baze podataka nikad ne prosljeđuju krajnjem korisniku, no sam SQL upit koji se generira s korisničkim unosom nije dobro formatiran i zaštićen. U takvim slučajevima mogu se koristiti takozvane slijepe SQL injekcije.
+**Blind SQL injection** je podskup **SQL injection ranjivosti**, gdje napadač može izvršiti SQL injekciju, ali ne može direktno dobiti vraćeni odgovor od baze.  Umjesto toga, jedina informacija koju napadač može dobiti o izvršavanju upita može biti, primjerice, je li baza vratila prazan odgovor, je li se dogodila greška ili koliko je vremena bazi podataka trebalo da generira odgovor.
-Glavna razlika između slijepih i „običnih“ SQL injekcija, jest da u slijepim SQL injekcijama nema konkretnih podataka koji se dohvaćaju SQL injekcijom iz sustava i vraćaju napadaču, nego napadač na domišljate i kreativne načine nađe način da napravi SQL injekciju i od baze podataka, često indirektno, sazna je li SQL upit konstruiran SQL injekcijom točan ili netočan.
+Napadač potom koristi tu informaciju kako bi konstruirao SQL upite oblika:
-Informacija koje se mogu ovim načinom iskorištavanja saznati su, na primjer:
-- postoji li korisnik "admin" u sustavu?
+<file>
+ako je uvjet X zadovoljen, napravi A, ako nije zadovoljen, napravi B.
+</file>
+Gdje A i B izazivaju dva različita stanja sustava koja je moguće detektirati.
+Primjeri ovakvih upita:
+. Kada se može znati je li se dogodila greška u bazi ili ne:
+<file>
+Ako je točno da postoji tablica "users",
+podijeli broj s nulom kako bi izazvao grešku.
+</file>
+. Kada se može razlikovati jedino je li baza vratila prazan odgovor ili ne:
+<file>
+Ako je točno da postoji korisnik "admin" u tablici "users",
+vrati tog korisnika.
+</file>
+. Kada se ne zna odgovor baze, ali se može znati koliko vremena je bazi podataka trebalo za odgovor:
+<file>
+Ako password korisnika "admin" počinje sa slovom "a",
+spavaj 5 sekundi (ili, na primjer, izvrši zahtjevno računanje kojem treba više vremena za izvođenje)
+</file>
+Napad ilustriran zadnjim primjerom, gdje se pomoću vremena izvršavanja upita eksfiltriraju podaci iz baze, naziva se **time-based blind SQL injection**.
+Kako bi se saznali podaci u bazi, rezultat izvršavanja upita se mora spregnuti s nekom informacijom o stanju sustava koju je moguće razlikovati. Budući da najčešće postoje samo dva stanja koja je moguće jasno razlikovati, i sam SQL upit konstruiran SQL injekcijom mora biti u kondicionalnom obliku, gdje se definira uvjet koji može biti ili zadovoljen ili ne, te se, ovisno o tome je li uvjet zadovoljen, izaziva stanje sustava koje je moguće razaznati.
+Primjer koji prikazuje kako bi se ovakvim upitima eksfiltrirala lozinka korisnika admin:
+<file>
+- počinje li lozinka korisnika "admin" sa slovom "a"? - NE
+- počinje li lozinka korisnika "admin" sa slovom "b"? - NE
+- počinje li lozinka korisnika "admin" sa slovom "c"? - DA
+- počinje li lozinka korisnika "admin" sa slovima "ca"? - NE
+- počinje li lozinka korisnika "admin" sa slovima "cb"? - NE
+- počinje li lozinka korisnika "admin" sa slovima "cc"? - DA
+- počinje li lozinka korisnika "admin" sa slovima "cca"? - NE
+...
+</file>
-- počinje li lozinka korisnika admin sa slovom "a"?
+Iz ovog primjera je jasno da je za eksfiltraciju informacija često potreban znatno veći broj upita nego pri uobičajenim SQL injekcijama. Zato se pri ovakvim napadima kreiraju skripte ili koriste gotovi alati kao **sqlmap** koji automatizirano generiraju velik broj zahtjeva i detektiraju je li uvjet u SQL injekciji bio zadovoljen ili nije te na kraju prikazuju eksfiltrirane informacije.
-- počinje li lozinka korisnika admin sa slovom "b"?
-- počinje li lozinka korisnika admin sa slovima abc?
-Iako su pitanja na koja možemo saznati odgovor samo potvrdna, odnosno jedine informacije koje možemo dobiti su da ili ne / točno ili netočno..., i dalje često možemo postaviti velik broj ovakvih pitanja sustavu i na svako ovo pitanje, pažljivim praćenjem promjena na stranici, možemo zaključiti koji su odgovori na postavljena pitanja. Često je onda idući korak napraviti skriptu ili koristiti već gotov alat, koji će umjesto automatski generirati i postaviti velik broj pitanja koja nas zanimaju i na kraju nam pokazati zabilježene odgovore.
 __**Primjeri**__ - **Zadatak s Hacknite platforme** - ** Banka **
@@ Line 114: / Line 161: @@
 Pokretanjem programa dobivamo hash vrijednost Sarine lozinke koja je <code>d4120d4f638a4bdd0f397e975b71b117583f4fdb35c60aeb5416fa922651a465</code>
-Koristimo crackstation.net za dobivanje para vrijednosti koja hashiranjem algoritmom SHA256 daje dobiveni hash, te uspješno dobivamo vrijednost <code>monitor123</code>, što je lozinka korisnika Sara. Dobivanje reversa hasha od lozinke s pomoću crackstationa prikazano na slici ispod.
+Koristimo crackstation.net za dobivanje para vrijednosti koja hashiranjem algoritmom SHA256 daje dobiveni hash, te uspješno dobivamo vrijednost <code>monitor123</code> što je lozinka korisnika Sara. Dobivanje originalne vrijednosti hasha lozinke s pomoću crackstationa prikazano je na slici ispod.
 {{blind_sql_8.png}}
-Sada se možemo uspješno ulogirati na formu admin portala s pomoću korisničkog imena //sara// i lozinke //monitor123//, ali nas nakon toga traži drugi faktor 2fa autentifikacije.
+Sada se možemo uspješno prijaviti na formu admin portala s pomoću korisničkog imena //sara// i lozinke //monitor123//, ali nas nakon toga traži drugi faktor 2fa autentifikacije.