Még akkor is, ha csak lazán követte az Anonymous és a LulzSec hackercsoportok eseményeit, valószínűleg hallott már olyan weboldalak és szolgáltatások feltöréséről, mint a hírhedt Sony hackek. Gondolkodott már azon, hogyan csinálják?
Számos eszközt és technikát alkalmaznak ezek a csoportok, és bár nem próbálunk kézikönyvet adni Önnek, hogy ezt saját maga végezze el, hasznos megérteni, mi történik. A támadások közül kettő, amelyet folyamatosan róluk hall, a „(Elosztott) Szolgáltatás megtagadása” (DDoS) és az „SQL Injections” (SQLI). Így működnek.
Kép készítette xkcd
Szolgáltatás megtagadása támadás
Mi az?
„Szolgáltatásmegtagadás” (néha „elosztott szolgáltatásmegtagadás” vagy DDoS) támadás akkor fordul elő, amikor egy rendszer, ebben az esetben egy webkiszolgáló, egyszerre annyi kérést kap, hogy a kiszolgáló erőforrásai túlterheltek, a rendszer egyszerűen lezárja és leáll. A sikeres DDoS-támadás célja és eredménye az, hogy a célszerveren található webhelyek nem érhetők el jogos forgalmi kérelmek számára.
Hogyan működik?
A DDoS támadás logisztikáját egy példával lehet a legjobban megmagyarázni.
Képzelje el, hogy egymillió ember (a támadók) találkozik azzal a céllal, hogy hátráltassa az X vállalat vállalkozását azzal, hogy leveszi a telefonos központját. A támadók úgy egyeztetnek, hogy kedden 9 órakor valamennyien felhívják az X vállalat telefonszámát. Valószínűleg az X vállalat telefonrendszere nem képes egyszerre egymillió hívást kezelni, így az összes bejövő vonalat lekötik a támadók. Ennek az az eredménye, hogy a törvényes ügyfélhívások (vagyis azok, amelyek nem a támadók) nem jutnak el, mert a telefonrendszer lekötve kezeli a támadók hívásait. Tehát lényegében az X vállalat potenciálisan veszít üzleti tevékenységéből, mivel a jogos kérelmek nem tudnak átjutni.
A webszerveren végrehajtott DDoS-támadás pontosan ugyanúgy működik. Mivel gyakorlatilag nincs mód arra, hogy megtudjuk, milyen forgalom származik a jogos kérelmektől és a támadóktól, amíg a webszerver nem dolgozza fel a kérést, ez a típusú támadás általában nagyon hatékony.
A támadás végrehajtása
A DDoS-támadás „nyers erő” jellegéből adódóan sok számítógépre van szüksége, amelyek mindegyike egyidejűleg támadásra van koordinálva. Visszatérve a call center példánkra, ehhez minden támadónak tudnia kell, hogy mind reggel 9-kor hívjanak, mind pedig akkor hívjanak. Bár ez az elv minden bizonnyal működni fog egy webszerver megtámadásakor, jelentősen könnyebbé válik, ha a zombikomputereket használják a tényleges emberekkel rendelkező számítógépek helyett.
Mint valószínűleg tudjátok, a rosszindulatú programok és a trójai programok számos változata létezik, amelyek a rendszerbe kerülve szunnyadnak, és időnként „telefonon haza” kérik az utasításokat. Ezen utasítások egyike lehet például az, hogy 9 órakor ismételt kéréseket küldjön az X vállalat webszerverére. Tehát az adott rosszindulatú program otthoni helyének egyetlen frissítésével egyetlen támadó azonnal összehangolhatja a veszélyeztetett számítógépek százezreit egy hatalmas DDoS-támadás végrehajtása érdekében.
A zombi számítógépek használatának szépsége nemcsak hatékonyságában, hanem névtelenségében is rejlik, mivel a támadónak valójában egyáltalán nem kell számítógépét használni a támadás végrehajtásához.
SQL Injection Attack
Mi az?
Az „SQL injection” (SQLI) támadás olyan kihasználás, amely kihasználja a gyenge webfejlesztési technikákat és általában a hibás adatbázis-biztonsággal kombinálva. A sikeres támadás eredménye a felhasználói fiók megszemélyesítésétől az adott adatbázis vagy szerver teljes kompromisszumáig terjedhet. A DDoS támadással ellentétben az SQLI támadás teljesen és egyszerűen megelőzhető, ha egy webalkalmazást megfelelően programoznak.
A támadás végrehajtása
Amikor bejelentkezik egy webhelyre, és megadja a felhasználó nevét és jelszavát, a hitelesítő adatok tesztelése érdekében a webalkalmazás futtathat egy lekérdezést, mint például:
Válassza ki a felhasználói azonosítót azokból a felhasználókból, ahonnan UserName = 'myuser' ÉS Password = 'mypass';
Megjegyzés: Az SQL lekérdezésben szereplő karakterláncértékeket egyetlen idézőjelben kell feltüntetni, ezért jelennek meg a felhasználó által megadott értékek körül.
Tehát a beírt felhasználónév (myuser) és jelszó (mypass) kombinációjának meg kell egyeznie a Felhasználók táblázatban szereplő bejegyzéssel, hogy visszatérjen a UserID-hez. Ha nincs egyezés, nem ad vissza UserID-t, így a bejelentkezési adatok érvénytelenek. Bár egy adott megvalósítás eltérhet, a mechanika meglehetősen szabványos.
Tehát most nézzünk meg egy sablon hitelesítési lekérdezést, amely helyettesítheti a felhasználó által az internetes űrlapon megadott értékeket:
Válassza ki a felhasználói azonosítót a felhasználók közül, ahol felhasználónév = '[user]' ÉS jelszó = '[pass]'
Első pillantásra ez egyszerű és logikus lépésnek tűnhet a felhasználók egyszerű validálásában, azonban ha ezen a sablonon a felhasználó által bevitt értékek egyszerű helyettesítését hajtják végre, akkor az érzékeny egy SQLI-támadásra.
Tegyük fel például, hogy a „myuser’–” be van írva a felhasználónév mezőbe, és a „wrongpass” be van írva a jelszóba. Egyszerű helyettesítést használva a sablon lekérdezésünkben ezt kapjuk:
Válassza ki a felhasználói azonosítót azokból a felhasználókból, ahonnan UserName = 'myuser' - 'ÉS Password =' wrongpass '
A kijelentés kulcsa a két kötőjel felvétele
(--)
. Ez az SQL utasítások kezdő megjegyzés tokenje, így a két kötőjel után megjelenő elemeket (beleértve) figyelmen kívül hagyják. Lényegében a fenti lekérdezést az adatbázis a következő módon hajtja végre:
Válassza ki a felhasználói azonosítót a felhasználók közül, ahol felhasználónév = 'saját felhasználó'
A kirívó kihagyás itt a jelszóellenőrzés hiánya. Azzal, hogy a két kötőjelet belefoglaltuk a felhasználói mezőbe, teljesen megkerültük a jelszóellenőrzési feltételt, és a saját jelszó ismerete nélkül „myuser” néven tudtunk bejelentkezni. Ez a lekérdezés manipulálása nem kívánt eredmények elérése érdekében SQL injekciós támadás.
Milyen kárt lehet okozni?
Az SQL injekciós támadást hanyag és felelőtlen alkalmazáskódolás okozza, és teljesen megelőzhető (amire egy pillanat alatt kitérünk), azonban az elérhető kár mértéke az adatbázis beállításától függ. Annak érdekében, hogy egy webalkalmazás kommunikálni tudjon a háttér-adatbázissal, az alkalmazásnak be kell jelentkeznie az adatbázisba (vegye figyelembe, hogy ez különbözik a felhasználó bejelentkezésétől magához a webhelyhez). Attól függően, hogy milyen engedélyeket igényel a webalkalmazás, ez a megfelelő adatbázis-fiók a meglévő táblákban szereplő írási és olvasási engedélyektől kezdve a teljes adatbázis-hozzáférésig bármit megkövetelhet. Ha ez most nem egyértelmű, néhány példa segíthet némi egyértelműségben.
A fenti példa alapján láthatja, hogy például a
"a felhasználó" - "," admin "-"
vagy bármely más felhasználónév, azonnal bejelentkezhetünk a webhelyre, mint felhasználó, a jelszó ismerete nélkül. Miután beléptünk a rendszerbe, nem tudja, hogy valójában nem mi vagyunk-e a felhasználók, így teljes hozzáféréssel rendelkezünk az adott fiókhoz. Az adatbázis-engedélyek nem biztosítanak ehhez biztonsági hálót, mert általában egy weboldalnak legalább olvasási / írási hozzáféréssel kell rendelkeznie a megfelelő adatbázisához.
Tegyük fel, hogy a webhely teljes mértékben ellenőrzi az adott adatbázist, amely lehetővé teszi rekordok törlését, táblák hozzáadását / eltávolítását, új biztonsági fiókok hozzáadását stb. Fontos megjegyezni, hogy egyes webalkalmazásoknak szüksége lehet ilyen típusú engedélyre, így nem automatikusan rossz dolog, hogy a teljes irányítást megadják.
Tehát annak bemutatására, hogy milyen károkat okozhat ebben a helyzetben, a fenti képregényben bemutatott példát vesszük figyelembe, a következők beírásával a felhasználónév mezőbe:
"Robert"; DROP TABLE felhasználók; - ".
Egyszerű helyettesítés után a hitelesítési lekérdezés a következőkké válik:
Válassza ki a felhasználói azonosítót a felhasználóktól, ahol felhasználónév = 'Robert'; DROP TABLE Felhasználók; - 'AND Password =' wrongpass '
Megjegyzés: a pontosvesszőt egy SQL-lekérdezésben használják egy adott utasítás végének és egy új utasítás elejének jelölésére.
Amit az adatbázis a következő módon hajt végre:
Válassza ki a felhasználói azonosítót a felhasználók közül, ahol felhasználónév = 'Robert'DROP TABLE felhasználók
Tehát éppúgy SQLI támadást használtunk a teljes Felhasználói táblázat törlésére.
Természetesen ennél sokkal rosszabb is lehet, mivel a megengedett SQL engedélyektől függően a támadó megváltoztathatja az értékeket, táblákat (vagy magát az egész adatbázist) szövegfájllá változtathatja, új bejelentkezési fiókokat hozhat létre, vagy akár eltérítheti az egész adatbázis-telepítést.
SQL injekciós támadás megakadályozása
Mint korábban már többször említettük, az SQL injekciós támadás könnyen megelőzhető. A webfejlesztés egyik sarkalatos szabálya, hogy soha nem bízik vakon a felhasználói bevitelben, mint ahogy mi tettük, amikor a fenti sablonlekérdezésben egyszerű helyettesítést hajtottunk végre.
Az SQLI-támadást könnyen meghiúsíthatja az úgynevezett bemenetek fertőtlenítése (vagy elkerülése). A fertőtlenítési folyamat valójában meglehetősen triviális, mivel lényegében csak annyit tesz, hogy minden beillesztett egyetlen idézet (’) karaktert megfelelően kezel, hogy ne lehessen őket egy SQL-utasítás belsejében idő előtt lezárni.
Például, ha "O'neil" -et akart keresni egy adatbázisban, akkor nem használhatott egyszerű helyettesítést, mert az O utáni egyetlen idézet idő előtt véget vet a karakterláncnak. Ehelyett az adott adatbázis escape karakterének használatával fertőtleníti. Tegyük fel, hogy egy beillesztett egyetlen idézetnél a escape karakter minden egyes idézetet egy \ szimbólummal előz meg. Tehát az „O’neal” -t „O \’ neil ”néven fertőtlenítenék.
Ez az egyszerű higiénés cselekmény nagyjából megakadályozza az SQLI támadását. Illusztrációként nézzük át korábbi példáinkat, és nézzük meg az ebből eredő kérdéseket, amikor a felhasználói bevitelt megtisztítják.
myuser '-
/
tévedés
:
Válassza ki a felhasználói azonosítót azokból a felhasználókból, ahonnan UserName = 'myuser \' - 'AND Password =' wrongpass '
Mivel a myuser utáni egyetlen idézet elkerülve van (vagyis a célérték részének tekinthető), az adatbázis szó szerint megkeresi a
"myuser" - ".
Ezen túlmenően, mivel a kötőjelek a karakterlánc értékében vannak, és nem maga az SQL utasítás, ezért azokat a célérték részének tekintjük, ahelyett, hogy SQL megjegyzésként értelmeznénk őket.
Robert '; DROP TABLE felhasználók; -
/
tévedés
:
Válassza ki a felhasználói azonosítót a felhasználóktól, ahol felhasználónév = 'Robert \'; DROP TABLE Felhasználók; - 'AND Password =' wrongpass '
Azáltal, hogy egyszerűen elkerüli az egyetlen idézetet Robert után, a pontosvessző és a kötőjel is a UserName keresési karakterláncban található, így az adatbázis szó szerint
"Robert"; DROP TABLE felhasználók; - "
a táblázat törlése helyett.
Összefoglalva
Míg a webes támadások fejlődnek, kifinomultabbá válnak, vagy egy másik belépési pontra összpontosítanak, fontos megjegyezni, hogy védekezzünk a kipróbált és igaz támadások ellen, amelyek számos szabadon elérhető „hackereszköz” ihletet szolgáltak ezek kihasználására.
Bizonyos típusú támadásokat, például a DDoS-t nem lehet könnyen elkerülni, míg másokat, például az SQLI-t. Az ilyen típusú támadások által okozott kár azonban a megtett óvintézkedések függvényében a kényelmetlenségtől a katasztrófáig terjedhet.
