How to hack a web site using SQL injection.

Security-all

Ezt találtam a hétvégén...
Érdemes megnézni ezt a (sajnos nagyon halk, de önmagáért beszélő) videót: http://www.appiant.net/exploit.wmv

A hozzá tartozó cikk itt: http://www.addict3d.org/index.php?page=viewarticle&type=security&ID=647…

Sajna én egyszerű mezei felhasználóként nem sokat konyítok ehhez, de tetszik ez a mágia :-)

  • 6311 megtekintés

( styg v | 2006. 05. 29., h – 15:54 )

Nincsen ebben semmi mágia. Egy dilettáns módon kivitelezett portálba történő behatolást láttunk egy egyszerű módszerrel. Ha jól láttam, a kliens oldali ellenőrzéseket iktatta ki, majd pedig a kihasználta azt a sületlenséget, hogy a szerver oldali programozó sima stringkonkatenációval állította össze az SQL utasítását.
Tehát nem a cracker volt ügyes, hanem a fejlesztő végzett pocsék munkát. Nagyjából-egészéből nyitva hagyta az autó ablakát, a slusszkulcsot pedig a kesztyűtartóban hagyta. A kocsit meg ellopták...
Ennyi.

Azért az sem lehet nyugodt, aki nem hagyta nyitva az autó ablakát, és nem hagyta a kulcsot a kesztyűtartóban.

Én pl. anno tüzetesen tanulmányoztam a postgreSQL dokumentációjának "security" fejezetét, és ennek megfelelően használtam pl. a pg_escape_string() függvényt az SQL injection megelőzésére.

Aztán most olvasom, hogy valami "not Unicode aware" kliensek esetében a pgescapestring() funkció eddig nem a várt módon működött; lényegében nem védett az SQL injection ellen. Emiatt most kiadtak egy biztonsági frissítést a postgreSQL-hez.

De ez egyben azt is jelenti, hogy a biztonságosnak tudott adatbázisom egészen mostanáig egyáltalán nem volt az :-(

(Azt leszámítva, hogy csak a belső hálózatról érhető el az adatbázisom; az apache "nobody" jogokkal fut; a "nobody" user pedig csak olvasási jogot kapott minden táblára.)

---
If you have money, use Windows!
However, if you also have a brain, use Linux!

"De ez egyben azt is jelenti, hogy a biztonságosnak tudott adatbázisom egészen mostanáig egyáltalán nem volt az :-("

Azert ez majdnem mindenre igaz am. Gondolj csak bele, nap mint nap olvassuk az ertesitoket sebezhetosegekrol, holott a sebezhetoseg fizikailag nem abban a pillanatban keletkezik amikor azt felfedezik, hanem mar honapokkal, akar evekkel elotte is benne volt, sot, attol meg ki is kialthattak a "legbiztonsagosabb"-nak, mert nem volt ismert sebezhetoseg.

Minden szoftver lukas - meg az is amit most hasznalunk -, csak nem mindegyikrol tudjuk, es amig nem valik nyilvanvalova, addig ugy hivjuk, hogy "biztonsagos" - amivel en mondjuk nem feltetlen ertek egyet, de pl egyes helyeken marketing szovegnek qrva uber tud lenni. :-)

---------------------
Ригидус а бетегадьбол

( szaty | 2006. 05. 29., h – 20:56 )

Sziasztok,

ha már szóba jött ez a dolog akkor kérdeznék egyet, nagyából ide vág.

Nemsokára kéne egy oldalt írnom (php-be tervezem) ami sql back-endet használ de még nem csináltam ilyet soha. A programozás részével semmi gond az menni fog simán, amitől félek az az hogy unatkozó embrek föltörik az oldalt. Igazából nagy titkot nem fogok őrizni az sql szerverben de nem szertném ha más is trukálhatna benne, gondolom ez érthető.

Szóval a kérdés az az hogy mit kéne feltéten kerülnöm? Ha van ilyen összállítás valhol a neten akkor légyszi linkeljétek be én még nem találtam ilyet.

Pl. mielött egy sztringet lefuttatsz, mint SQL lekérdezést, akkor elötte alaposan győzödj meg róla, hogy a sztringben valóban az található -e, amit szeretnél?
Különösképpen fontos ez olyankor, ha a lekérdezést bizonyos, felhasználó által megadott adatokból állítod össze.

--- GTK programozás C nyelven ---
http://hu.wikibooks.org/wiki/GTK%2B_programoz%C3%A1s_C_nyelven

mysql_real_escape_string()

http://hu.php.net/manual/hu/function.mysql-real-escape-string.php

idezet:
"
mysql_real_escape_string -- Levédi egy stringben a speciális karaktereket egy SQL lekérdezés számára
Leírás
string mysql_real_escape_string ( string unescaped_string [, resource link_identifier] )

Levédi a speciális karaktereket az unescaped_string -ben, figyelembe véve az aktuális kapcsolat karakterkészletét. Tehát biztonságos, ha mysql_query()-n belül használod. Ha bináris adatot akarsz beszúrni, akkor ezt a függvényt kell használnod.

A mysql_real_escape_string() a MySQL könyvtár mysql_real_escape_string függvényét hívja meg, amely visszaperjeleket illeszt a következõ karakterek elé: \x00, \n, \r, \, ', " és \x1a.

Ezt a függvényt mindig használhatod (néhány kivétellel) arra, hogy az
adatokat biztonságossá tedd beszúrás elõtt.
"

persze letezik mas DBMSekhez is phpban, ez csak pelda

Keress rá a CGI security-re.

Általánosan biztosan igaz, hogy bármit, ami a kliens felől érkezett, validálni kell felhasználás előtt. Szám tényleg szám? Precision+scale megfelelő? String nem túl hosszú? Ha a string kulcsszó: szerepel egy előre definiált szótárban? Spec karakterek szerepelnek benne, ha igen, escape-elni sql vagy bármi felé. Stb...

Kliens javascript a kényelmet javíthatja csak, validálni nem szabad vele.

Köszi a válaszokat, mindenképp így fogok eljárni. Igazábol ezek szerint nem lessz nehéz dolgom mert főleg csak olvasni kell SQL-ből, és föleg fix dolgokat, vagyis nem igazán a fehasználótól függ, egy lekérdezés. Pl kell egy galériát írnom aminál meghatározhatja a weblap látogatója hogy a-z vagy z-a rendezéssel jelnjen meg.

Mindezek ellenére további jótanácsokat szívesen fogadok.

"nem igazán a fehasználótól függ, egy lekérdezés. Pl kell egy galériát írnom..."

Ezt a felhasználófüggetlenséget hogy oldod meg? Nem lehet pl. kategóriákra keresni? Mert ha igen, akkor annak a legkényelmesebb (és egyben legveszélyesebb) módja, hogy átadod a kliensnek a kategóriák azonosítóit, aztán a klienstől visszakapott (kiválasztott) azonosítót hozzáadod egy sql lekérdezéshez.

És itt jön az, amire mindenki figyelmeztetett, hogy ne bízz abban, hogy az, amit a klienstől visszakaptál, az tényleg csak egy kategória azonosító; mert lehet bármi.

Ezért Madman vagy Syntem javaslatai erősen megszívlelendők. Mindenféleképpen vedd figyelembe a php és a mysql dokumentáció "boztonság" fejezeteit.

És az én példámon pedig azt is láthattad, hogy a te munkád akkor sem ér véget, amikor az adatbázist elkészítetted. Azután is figyelned kell majd a biztonsági értesítőket, hogy nem derült-e ki valami friss apache/php/mysql sebezhetőség, amit sürgősen be kell foltozni.

---
If you have money, use Windows!
However, if you also have a brain, use Linux!

igen ez érthető de nekem tényleg roppant egszerű dolgom lessz, egy menhelynek az oldalát kell megcsinálnom (vagyis megírni php-ben) és ott nem nagyon kell más mint hogy kiarkja egy weboldalra a blökik képét. De azért kösz a tanácsot oda fogok figyelni nagyon minden változót leellenőrzök amit a klienstől kapok vissza.

Egyépként olyan kényelmes helyzetben vagyok hogy a szerver nem az enyém amin a honlap lessz nem én tartom karban magyarul arra hogy a bugfixek fölkerüljenek nem nekem kell figyelnem. És ráadásul egy profi informatikus csinálja szóval még ért is hozzá. Pl arra sem nekem kell figyelnem hogy a php biztonságosan legyen konfigurálva

( syntern | 2006. 05. 29., h – 22:34 )

Java, JDBC, PreparedStatement. És nagyon sok fejfájástól megkímélhetitek magatokat.