Forum » Informacijska varnost » SQL injection napad
SQL injection napad
Yacked2 ::
Živjo,
mene pa zanimajo SQL injection napadi. Vem da je ilegalno to poiskušati na tujih straneh, zato bi postavil neke vrste virualni laboratorij, ter se stvari lotil tam. Zaenkrat imam Virualno mašino z WinXP na katerem je Apache server ter PHP5, verjetno bom moral naložiti še kaj v povezavi z SQL kajne ?
Želel bi primere ranljivih strani, da bi si jih naložil v moj server ter potem poiskušal hackint. Pa me zanima če je dovolj:
na netu najdem ranjivo stran-->Shranim celotno stran, ter to kopiram v moj root fajel ali je potrebno še kaj drugega ?
Oziroma, če je na netu kakšna stran z nekakšnimi challengi, kjer bi lahko v miru poiskušal SQL napade.
LP
Yacked2
mene pa zanimajo SQL injection napadi. Vem da je ilegalno to poiskušati na tujih straneh, zato bi postavil neke vrste virualni laboratorij, ter se stvari lotil tam. Zaenkrat imam Virualno mašino z WinXP na katerem je Apache server ter PHP5, verjetno bom moral naložiti še kaj v povezavi z SQL kajne ?
Želel bi primere ranljivih strani, da bi si jih naložil v moj server ter potem poiskušal hackint. Pa me zanima če je dovolj:
na netu najdem ranjivo stran-->Shranim celotno stran, ter to kopiram v moj root fajel ali je potrebno še kaj drugega ?
Oziroma, če je na netu kakšna stran z nekakšnimi challengi, kjer bi lahko v miru poiskušal SQL napade.
LP
Yacked2
Korak naprej ni vedno ustrezen...sploh če si na robu prepada!
- premaknil iz Znanost in tehnologija: bluefish ()
tomi_m ::
Poznaš SQL sintakso? Poznaš vsaj v teoriji kako naj bi se ti napadi izvajali? Kaj bi rad dosegel?
Ne maram preveč ScriptKiddie-v
Ne maram preveč ScriptKiddie-v
Yacked2 ::
Ja v teoriji približno vem kako se stvar izpelje, ter kaj kakšna koda naredi. Rad bi to stestiral če je to to. Svoje znanje dopolnil, itd....
Korak naprej ni vedno ustrezen...sploh če si na robu prepada!
tomi_m ::
Jaz bi naredil takole:
Poiščeš znani exploit (dobiš verzijo PHPja, CMSja in MySQLa), namestiš dotični komplet (PHP, CMS, MySQL) in probaš, če ga lahko ponoviš in kako.
Potem pa greš v lov za neznanimi exploiti.... ta bo sicer težka ampak... očitno se želiš učiti.
Poiščeš znani exploit (dobiš verzijo PHPja, CMSja in MySQLa), namestiš dotični komplet (PHP, CMS, MySQL) in probaš, če ga lahko ponoviš in kako.
Potem pa greš v lov za neznanimi exploiti.... ta bo sicer težka ampak... očitno se želiš učiti.
x3ca ::
PHP5,PDO,prepared statements.
Hah, če verzija nekaj omogoča, še ne pomeni da ljudje to uporabljajo! Daleč od tega, še zmeraj jih veliko sestavlja queryje z mysql_query, tudi na verziji 5, tudi ko pišejo nove izdelke, da o starih ne govorim. In tudi če bi uporabljali PDO, ni nujno, da bi vse napisali s prep.statementi Poleg tega veljajo samo za vrednosti, ki jih vnašaš v bazo. Če pa uporabiš npr. ime polja ali tabele kot spremenljivko ter ne preverjaš inputa, se lahko tudi hitro zaj****, tukaj ti prepared statementi ne pomagajo. Je pa PDO drgač ful luštna zadeva in ne vem zakaj je folk ne uporablja.
MisterR ::
Zato pa sem napisal, če je uporabljen php5. Če imaš na serveru nameščen php5 še ne pomeni da ga uporabljaš.
Ni pa mi jasno tole:
Ni pa mi jasno tole:
Če pa uporabiš npr. ime polja ali tabele kot spremenljivko ter ne preverjaš inputa
x3ca ::
Okej razumem, kam si ciljal :)
Ja recimo da je variabla kater field v bazi sploh hočeš sprement in imaš potem sql: UPDATE table SET $field = 'neki', no tega $field ne moreš parametrizirat, prav tako velja to za SELECT neki FROM table WHERE column IN ($bla, $bla2) -> tega se tud ne da :) Torej v primeru, da gre za userjev input, maš neki dodatnega dela s tem, če ne lah lih tko fašeš injection.
Ja recimo da je variabla kater field v bazi sploh hočeš sprement in imaš potem sql: UPDATE table SET $field = 'neki', no tega $field ne moreš parametrizirat, prav tako velja to za SELECT neki FROM table WHERE column IN ($bla, $bla2) -> tega se tud ne da :) Torej v primeru, da gre za userjev input, maš neki dodatnega dela s tem, če ne lah lih tko fašeš injection.
techfreak :) ::
RockyS: Lahko uporabljaš php5 interpreter, ampak to še ne pomeni da uporabljaš PDO. Doma imam nekaj PHP knjig starih 5+ let in niti mysql_real_escape_string ne omenjajo, internetni tutoriali pa tudi niso kaj boljši.
Medtem pa ne najdeš (ali pa zelo težko) tutoriale za C#/Python (in verjetno tudi ostale jezike), ki ne bi uporabljali metod ki poskrbijo za zaščito pred SQL injection.
x3ca: Osebno se pri imenih tabel, polj, shranjenih procedur, itd. držim naslednjega regexa: ^[A-z_]+$. Veliko lažje je (če je že nujno) pregledati ime polja za ta regex, kot pa npr. uporabniški vnos teksta.
Načeloma pa nisem prepričan, če takšni načini spadajo pod best practices.
Medtem pa ne najdeš (ali pa zelo težko) tutoriale za C#/Python (in verjetno tudi ostale jezike), ki ne bi uporabljali metod ki poskrbijo za zaščito pred SQL injection.
x3ca: Osebno se pri imenih tabel, polj, shranjenih procedur, itd. držim naslednjega regexa: ^[A-z_]+$. Veliko lažje je (če je že nujno) pregledati ime polja za ta regex, kot pa npr. uporabniški vnos teksta.
Načeloma pa nisem prepričan, če takšni načini spadajo pod best practices.
Phantomeye ::
men je ful grozn, k vids kok velik strani ima ranljivost v sql. Pr enmu kolegu sm za hec mal tapkal po url-ju, k ma spletno trgovino. k sm najdu error, sem se šel script kiddya, potegnu dol en program, vnesu url ranljivosti bum, celotna baza zaposlenih, artiklov, itd...
cist tko. kok je sploh sql injection napad izsledljiv (pac ce samo tipaš po bazi in nicesar ne spreminjas?)
cist tko. kok je sploh sql injection napad izsledljiv (pac ce samo tipaš po bazi in nicesar ne spreminjas?)
techfreak :) ::
Spletni strežnik ima loge obiskanih URLjev in piše kateri IP jih je obiskal.
Edit: To velja v primeru GET zahtevkov (example.com/getnews.php?id='; SELECT * FROM users), vsebina POST zahtevkov se ponavadi ne beleži.
Edit: To velja v primeru GET zahtevkov (example.com/getnews.php?id='; SELECT * FROM users), vsebina POST zahtevkov se ponavadi ne beleži.
Zgodovina sprememb…
- spremenil: techfreak :) ()
cen1 ::
Ne moreš ti lokalno poskušat heknit ene spletne strani ker se vsak GET/POST zahtevek obdela na njihovih serverjih. Če ti prekopiraš html lokalno ti to čisto nič ne pomaga. Boš moral kar direktno na strani poskušat, tako ali drugače.
MisterR ::
Okej razumem, kam si ciljal :)
Ja recimo da je variabla kater field v bazi sploh hočeš sprement in imaš potem sql: UPDATE table SET $field = 'neki', no tega $field ne moreš parametrizirat, prav tako velja to za SELECT neki FROM table WHERE column IN ($bla, $bla2) -> tega se tud ne da :) Torej v primeru, da gre za userjev input, maš neki dodatnega dela s tem, če ne lah lih tko fašeš injection.
Če uporabljaš MVC pristop in PDO lahko.
techfreak :) se strinjam s tabo. Za nazaj definitivno ne boš šel mysql_* kode spreminjat v PDO, ampak če začneš projekt iz nule, ali pa če imaš čas da postopoma posodobljaš kodo.
Osebno sem z uporabo PDO pridobil dosti, je pa res da sem se ga OK (torej delno) naučil tudi porabil kar nekaj časa, sploh ko začneš uporabljati flage in podobne zadeve. Mi pa še zmeraj ni jasno zakaj UTF-8 ne deluje "out of the box" in je potrebno nastavljat flag.
Drugače pa upam na čimprejšno vpeljavo spremenljivk brez $ in uporabo podatkovnih tipov.
Mesar ::
techfreak :) je izjavil:
Spletni strežnik ima loge obiskanih URLjev in piše kateri IP jih je obiskal.
Edit: To velja v primeru GET zahtevkov (example.com/getnews.php?id='; SELECT * FROM users), vsebina POST zahtevkov se ponavadi ne beleži.
Vsebina _običajno_ ne, zahtevek pa.
Your turn to burn!
Phantomeye ::
techfreak :) je izjavil:
Spletni strežnik ima loge obiskanih URLjev in piše kateri IP jih je obiskal.
Edit: To velja v primeru GET zahtevkov (example.com/getnews.php?id='; SELECT * FROM users), vsebina POST zahtevkov se ponavadi ne beleži.
ja, to mi je jasno... torej v bistvu, razen ce adminu ne zapaše mau logov gledat, nekak sql injection ni glih na radarju?
(ceprav vem, da obstajajo programi, ki detektirajo te stvari, ampak to je ze druga zgodba.
cen1 ::
Čist odvisno od sysadmina.. če je paranoja lahko logira čisto vsak request. Po defaultu se tega seveda ne dela.
Yacked2 ::
Aha..se pravi do z pri sebi nemorem narediti ničesar. A obstaja kakšna stran kjer je dovoljeno mislim je namenjena za testiranje SQL napadov ?
Korak naprej ni vedno ustrezen...sploh če si na robu prepada!
Roadkill ::
Začni tule: https://www.owasp.org/index.php/Categor...
Postavi serverček v virtualko in gasa. Lepo počasi in od začetka.
Potem je pa tule en lep seznam: http://g0tmi1k.blogspot.com/2011/03/vul...
Postavi serverček v virtualko in gasa. Lepo počasi in od začetka.
Potem je pa tule en lep seznam: http://g0tmi1k.blogspot.com/2011/03/vul...
Ü
cen1 ::
Najbolje je če greš v divjino in kar poskušaš hekat.. pregledaš stran in poskušaš ugotovit kateri formi/linki/strani poizvedujejo po bazi in zamenjaš normalna poizvedovanja z sql injection. Če se zgodi kaj čudnega potem si na dobri poti, če ti vrže samo navaden error da nečesa ne najde ipd potem pač ne bo šlo. Najbolje da deluješ preko Tor omrežja, če slučajno kaj najdeš pa obvestiš lastnika strani, vaj upam da je to tvoj namen.
Postavljati virtualke in neke namišjene strani ni niti približno produktivno, niti realen prikaz spleta. :)
Predvsem glej za kakšne forme kjer ti ponudijo že vnaprej seznam, npr dropdown list. Potem spremeniš POST request v sql injection in to je to. PHP noobi največkrat naredijo to napako da predvidevajo da je vse kar pošlje uporabnik preko determinističnih obrazcev OK, to je pa zato ker nimajo pojma kako http sploh deluje. Nekateri celo dodajajo podatke v hidden inpute in mislijo da uporabnik tega ne more videt.. pri self-made straneh imaš največ šans da kaj odkriješ, pri kakšnih znanih sistemih ki jih uporablja veliko ljudi pa bolj malo verjetno, mogoče ugotoviš da ima kak vBulletin nameščen plugin ki ima luknjo in prek tega hekneš ipd.
Postavljati virtualke in neke namišjene strani ni niti približno produktivno, niti realen prikaz spleta. :)
Predvsem glej za kakšne forme kjer ti ponudijo že vnaprej seznam, npr dropdown list. Potem spremeniš POST request v sql injection in to je to. PHP noobi največkrat naredijo to napako da predvidevajo da je vse kar pošlje uporabnik preko determinističnih obrazcev OK, to je pa zato ker nimajo pojma kako http sploh deluje. Nekateri celo dodajajo podatke v hidden inpute in mislijo da uporabnik tega ne more videt.. pri self-made straneh imaš največ šans da kaj odkriješ, pri kakšnih znanih sistemih ki jih uporablja veliko ljudi pa bolj malo verjetno, mogoče ugotoviš da ima kak vBulletin nameščen plugin ki ima luknjo in prek tega hekneš ipd.
Yacked2 ::
Ja želim samo svoje tehnike testirat in jih izbolšat. A je samo TOR dovolj, da nebo slučajno kaj narobej, če naletim na stran z paranoičnim adminom ?
Korak naprej ni vedno ustrezen...sploh če si na robu prepada!
Vredno ogleda ...
Tema | Ogledi | Zadnje sporočilo | |
---|---|---|---|
Tema | Ogledi | Zadnje sporočilo | |
» | PHP problemOddelek: Programiranje | 1158 (860) | BivšiUser2 |
» | Branje slik jpg iz MySQL z PHPOddelek: Izdelava spletišč | 2422 (2040) | a-ptuj1 |
» | Spletno gostovanje v oblaku - hitrost najbolj pomembnaOddelek: Izdelava spletišč | 3280 (2847) | illion |
» | Vdor v MySQL.com z vrivanjem SQLOddelek: Novice / Varnost | 8521 (6399) | techfreak :) |
» | Raziskava o ranljivosti spletnih strani z SQL bazami podatkovOddelek: Novice / Varnost | 4943 (4279) | sverde21 |