This is an old revision of the document!
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 kojiu 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.
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. Informacija koje se mogu ovim načinom iskorištavanja saznati su, na primjer:
- postoji li korisnik “admin” u sustavu?
- počinje li lozinka korisnika admin sa slovom “a”?
- 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
Sara je razvojna programerka za banku. Napravila je aplikaciju za e-banking, budući da je sigurnost e-banking aplikacija vrlo važna skenirala je aplikaciju raznim sigurnosnim alatima, no nije pronašla nikakve ranjivosti. Također, za dodatnu razinu sigurnosti implementirala je dvofaktorsku autentifikaciju. Ipak, misli da bi bilo dobro da i vi provjerite sigurnost aplikacije prije nego što bude puštena u produkciju. Hint: objavljen je izvorni kod Napomena: Nije potrebno bruteforceati drugi faktor. http://chal.platforma.hacknite.hr:12009 Flag je u formatu CTF2023[brojevi].
Pri prvom pregledu stranice, vidimo da se stranica sastoji od početne stranice, login forme, admin portala i stranice za resetiranje lozinke. Pri isprobavanju login forme i admin portala, za unesene pokušaje korisničkim imena i lozinki dobivamo samo generičan odgovor „Krivo korisničko ime ili lozinka“. Pri pokušaju unošenja različitih imena u formu za resetiranje lozinke dobijemo odgovor „korisničko ime ne postoji“. Možemo pretpostavit da ako ovdje pogodimo barem ime nekog korisnika da ćemo dobit potvrdan odgovor. U tekstu zadatka je napisano da je Sara napravila stranicu, te pokušajem unosa imena „sara“ u formu za resetiranje lozinke dobivamo odgovor „Pozdrav, sara, reset lozinke mailom još nije dostupan. Lozinku možete resetirati u jednoj od naših poslovnica“.
TODO - slika ovdje
Pokušajem unosa jednostrukih navodnika „ ' „ ne dobivamo nikakvu poruku, niti da korisnik ne postoji, niti poruku pozdrava, što može upućivati na to da je SQL injection moguć ili je unos filtriran, te da smo možda prouzročili SQL grešku pokretanjem slanjem ovog unosa, no poslužitelj ne prosljeđuje poruke greške.
TODO - slika ovdje
Uz zadatak je dostupan i dio izvornog koda. Analizom djela koda za resetiranje lozinke u datoteci reset.php, vidimo da SQL upit nije formatiran na siguran način, te da bi potencijalno bila moguća SQL injekcija. Također vidimo da se nakon dohvata SQL upita iz baze, ovisno o tome je li dohvaćena neka n-torka iz baze ili ne, vraća ili odgovor da korisničko ime ne postoji, ili poruka pozdrava.
TODO - slika ovdje