Számos eszközt és technikát használnak ezek a csoportok, és amíg nem próbálunk kézikönyvet adni Önnek, akkor érdemes megértenünk, mi folyik itt. A támadások közül kettő, amelyekről következetesen hallott róluk, a "(Distributed) Denial of Service" (DDoS) és az SQL injection (SQLI). Így működnek.
Kép: xkcd
Denial of Service támadás
Mi az?
A "denial of service" (néha "elosztott denial of service" vagy DDoS) támadás akkor fordul elő, amikor egy rendszer, ebben az esetben egy webszerver, annyi kérelmet kap egyszerre, hogy a szerver erőforrások túlterheltek, a rendszer egyszerűen bezár és leáll. A sikeres DDoS-támadás célja és eredménye, hogy a célszerveren található webhelyek nem érhetők el a forgalmi igényekhez.
Hogyan működik?
A DDoS-támadás logikáját legjobban egy példával lehet magyarázni.
Képzeljen el egy millió embert (a támadókat), hogy összegyűljenek azzal a céllal, hogy megakadályozzák a X társaság tevékenységét a hívóközpont leállításával. A támadók összehangolják, így kedden 9 órakor mindannyian felhívják a X társaság telefonszámát. Valószínűleg a X vállalat telefonrendszere nem képes egyszerre több millió hívást kezelni, így a bejövő vonalakat a támadók kötik össze. Az eredmény az, hogy a legális ügyfélhívások (azaz azok, amelyek nem a támadók) nem jutnak át, mert a telefon rendszerét lekötik a támadók által kezdeményezett hívások kezelése. Tehát a X társaság potenciálisan elveszíti az üzleti tevékenységet, mivel a törvényes kérések nem tudnak átmenni.
A webszerverre vonatkozó DDoS támadás pontosan ugyanúgy működik. Mivel gyakorlatilag nem lehet tudni, hogy a forgalom jogszerű kérelmekről és támadókról származik-e, mielőtt a webszerver feldolgozza a kérelmet, az ilyen típusú támadások jellemzően nagyon hatékonyak.
A támadás végrehajtása
A DDoS-támadás "brute force" jellegének köszönhetően sok számítógépre van szüksége, amelyek egyidejűleg támadnak. Hívásközpontunk példájának felülvizsgálata esetén mindegyik támadónak mindenképpen tudnia kell, hogy 9:00 órakor hívja és ténylegesen hívja az adott időpontban. Bár ez az elv minden bizonnyal akkor fog működni, amikor megtámadják a webszervert, akkor sokkal egyszerűbb lesz, ha zombi számítógépeket használnak a tényleges embereket használó számítógépek helyett.
Mint valószínűleg tudja, sok malware és trójai változata van, amelyek egyszer a rendszereden aludtak és néha "telefonálnak" az utasításokért. Ezen utasítások egyikének például lehet az, hogy ismételt kéréseket küldjenek a X társaság webszerverére 9.00 órakor. Tehát egy adott frissítéssel a megfelelő kártevők otthoni helyére egyetlen támadó azonnal összehozhat több százezer veszélyeztetett számítógépet, hogy hatalmas DDoS támadást hajtson végre.
A zombi számítógépek kihasználásának szépsége nemcsak hatékonysága, hanem anonimitása is, hiszen a támadónak egyáltalán nem kell a számítógépet használni a támadás végrehajtásához.
SQL injekciós támadás
Mi az?
Az "SQL injektálás" (SQLI) támadás olyan kizsákmányolás, amely kihasználja a rossz webes fejlesztési technikákat, és általában a hibás adatbiztonsággal kombinálva. A sikeres támadás eredménye egy adott felhasználói fiók teljesítésétől a megfelelő adatbázis vagy szerver teljes kompromisszumáig terjedhet. A DDoS-támadástól eltérően egy SQLI-támadás teljesen és könnyen megelőzhető, ha egy webes alkalmazást megfelelően programoznak.
A támadás végrehajtása
Amikor bejelentkezik egy weboldalra, és megadja a felhasználónevét és a jelszavát, a hitelesítő adatok teszteléséhez a webes alkalmazás a következőképpen futtathat egy lekérdezést:
SELECT UserID FROM Users WHERE UserName='myuser' AND Password='mypass';
Megjegyzés: az SQL lekérdezésben lévő karakterláncértékeket egyetlen idézőjelben kell elhelyezni, ezért jelenik meg a felhasználó beírt értékei köré.
Tehát a beírt felhasználónév (myuser) és a jelszó (mypass) kombinációja meg kell egyeznie egy bejegyzéssel a Felhasználók táblában annak érdekében, hogy a UserID visszaküldésre kerüljön. Ha nincs egyezés, a UserID nem kerül visszaadásra, így a bejelentkezési hitelesíté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ük meg a sablon hitelesítési lekérdezést, amely helyettesítheti azokat a értékeket, amelyeket a felhasználó belép a webes űrlapba:
SELECT UserID FROM Users WHERE UserName='[user]’ AND Password='[pass]’
Első pillantásra ez egyszerű és logikus lépésnek tűnhet a felhasználók könnyű érvényesítéséhez, azonban ha a felhasználó által megadott értékek egyszerű helyettesítésére kerül sor, akkor ez SQLI támadásra érzékeny.
Tegyük fel például, hogy a "myuser'-" be van írva a felhasználói név mezőbe, és a "wrongpass" szerepel a jelszóban. Az egyszerű helyettesítést a sablon lekérdezésében kaptuk ezt:
SELECT UserID FROM Users WHERE UserName='myuser'--' AND Password='wrongpass'
Ennek a kijelentésnek a kulcsa a két kötőjel beillesztése
(--)
. Ez az SQL utasításokhoz tartozó megjegyzések tokenje, tehát a két kötőjel (befogadó) után megjelenő események figyelmen kívül maradnak. Lényegében a fenti lekérdezést az adatbázis hajtja végre:
SELECT UserID FROM Users WHERE UserName='myuser'
A téves mulasztás itt a jelszavas ellenőrzés hiánya.A két kötőjelet a felhasználói mező részeként teljesen kiiktatta a jelszó ellenőrzésének feltételeit, és a "myuser" -ként jelentkezhetett a megfelelő jelszó ismerete nélkül. A lekérdezés manipulálása a nem szándékolt eredmények előállításához egy SQL injekciós támadás.
Milyen károkat lehet tenni?
Az SQL injekciós támadást a gondatlan és felelőtlen alkalmazáskódolás okozza, és teljesen megakadályozható (amelyet egy pillanatra fedezünk), azonban a károsodás mértéke az adatbázis beállításától függ. Annak érdekében, hogy egy webes alkalmazás kommunikálhasson a háttéradatbázisával, az alkalmazásnak be kell jelentkeznie az adatbázisba (megjegyzendő, hogy ez különbözik a weboldalon történő bejelentkezéshez). Attól függően, hogy milyen engedélyek szükségesek a webes alkalmazáshoz, a megfelelő adatbáziskiszolgáló csak a meglévő táblázatok olvasási / írási engedélyétől követelheti meg a teljes adatbázis-hozzáférést. Ha ez most nem világos, néhány példa segíthet bizonyos tisztaságot.
A fenti példa alapján láthatja, hogy például a
'youruser'--', 'admin'--'
vagy bármely más felhasználónevet, azonnal bejelentkezhetünk az oldalra úgy, hogy a felhasználó a jelszó ismerete nélkül. Miután a rendszerben vagyunk, nem tudjuk, hogy valójában nem a felhasználó, így teljes hozzáféréssel rendelkezünk a megfelelő fiókhoz. Az adatbázis-jogosultságok nem nyújtanak biztonsági hálózatot, mert általában egy webhelynek legalább olvasási / írási hozzáférést kell biztosítania a megfelelő adatbázisához.
Most tegyük fel, hogy a weboldal teljes mértékben ellenőrzi a megfelelő adatbázisát, amely lehetővé teszi a rekordok törlését, táblák hozzáadása / eltávolítását, új biztonsági számlák hozzáadását stb. Fontos megjegyezni, hogy egyes webes alkalmazásoknak ehhez az engedélyhez kell nem teljesen rossz a teljes ellenőrzés.
Annak érdekében, hogy illusztráljuk az ebben a helyzetben elvégezhető károkat, a fenti képen a példában szereplő példát a felhasználói név mezőbe írjuk be:
'Robert'; DROP TABLE Users;--'.
Az egyszerű helyettesítés után a hitelesítési lekérdezés:
SELECT UserID FROM Users WHERE UserName='Robert'; DROP TABLE Users;--' AND Password='wrongpass'
Megjegyzés: az SQL lekérdezésben szereplő pontosvessző egy adott utasítás végét és egy új utasítás kezdetét jelöli.
Melyiket az adatbázis hajtja végre:
SELECT UserID FROM Users WHERE UserName='Robert'
DROP TABLE Felhasználók
Szóval ilyen módon SQLI támadást használunk a teljes felhasználói táblázat törléséhez.
Természetesen sokkal rosszabb is lehet, mivel az engedélyezett SQL engedélyek függvényében a támadó az értékeket, a dump táblákat (vagy az egész adatbázist) megváltoztathatja egy szöveges fájlba, új bejelentkezési fiókokat hozhat létre, vagy akár az egész adatbázis telepítését is eltéríti.
SQL injection támadás megakadályozása
Mint korábban már említettük, az SQL injekciós támadás könnyen megelőzhető. A webfejlesztés egyik legfontosabb szabálya, hogy soha nem vakítod meg a felhasználói beviteledet, ahogyan azt tettük, amikor egyszerű helyettesítést hajtott végre a fenti sablon lekérdezésünkben.
Az SQLI támadást könnyen meghiúsítja az úgynevezett fertőtlenítés (vagy elszökés). A fertőtlenítés folyamata valójában nagyon triviális, hiszen minden lényegében az inline single quote (') karaktereket úgy kezeli, hogy azok nem használhatók arra, hogy az SQL utasításon belüli sztringet idő előtt megszüntessék.
Például, ha egy adatbázisban "O'neil" -t szeretne keresni, akkor nem használhat egyszerű helyettesítést, mert az O pontozás utáni egyetlen pontozás a sztring túl korai befejezéséhez vezetne. Ehelyett a megfelelő adatbázishoz tartozó menekülési karakter használatával fertőtleníti. Tegyük fel, hogy a bejövő egyéni idézet escape karaktere minden egyes idézőjelet egy szimbólummal előzi meg. Tehát az "O'neal" -et "O 'neil" -ként kell tisztítani.
Ez az egyszerű cselekedet nagyjából megakadályozza az SQLI támadást. Az illusztráció érdekében nézzük meg korábbi példáinkat, és nézzük meg a kapott lekérdezéseket, amikor a felhasználói beavatkozás megszűnik.
myuser'--
/ wrongpass:
SELECT UserID FROM Users WHERE UserName='myuser'--' AND Password='wrongpass'
Mivel a myuser után megjelenő egyetlen idézet (vagyis a célérték része), az adatbázis szó szerint megkeresi a UserName
'myuser'--'.
Ezenkívül, mivel a kötőjelek szerepelnek a string értéken belül, és nem magának az SQL utasításnak, akkor azok a célérték részét képezik, nem pedig SQL megjegyzésként értelmezhetők.
Robert'; DROP TABLE Users;--
/ wrongpass:
SELECT UserID FROM Users WHERE UserName='Robert'; DROP TABLE Users;--' AND Password='wrongpass'
Egyszerűen elhagyva az egyetlen idézetet Robert után, mind a pontosvessző, mind a kötőjel a UserName keresőhalmazban található, így az adatbázis szó szerint keresni fog
'Robert'; DROP TABLE Users;--'
ahelyett, hogy végrehajtaná a táblázat törlését.
Összefoglalva
Miközben a webes támadások fejlődnek, kifinomultabbak vagy egy másik belépési pontra összpontosítanak, fontos megjegyezni, hogy megvédik a kipróbált és valódi támadásokat, amelyek számos szabadon hozzáférhető "hacker-eszköz" ihletét jelentették.
A támadások bizonyos típusai, például a DDoS, nem könnyű elkerülni, míg mások, például az SQLI. Azonban az ilyen típusú támadások által okozott károk bárhol terjedhetnek a katasztrofális kényelmetlenségtől a meghozott óvintézkedések függvényében.
