26Aug
Annak ellenére, hogy csak lazán követte az Anonymous és a LulzSec hackercsoportok eseményeit, valószínűleg hallott már arról, hogy weboldalakat és szolgáltatásokat csapkodtak, mint a hírhedt Sony hackeket. Elgondolkodott már valaha arról, hogyan csinálják?
Számos olyan eszköz és technika létezik, amelyeket ezek a csoportok használnak, és amíg nem próbálunk kézikönyvet adni Önnek, akkor érdemes megérteni, 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 Attack
Mi ez?
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érést kap egyszerre, hogy a szerver erőforrások túlterheltek, a rendszer egyszerűen bezárfel és le. 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 magyarázhatja.
Képzeljen el egy millió embert( a támadókat), hogy összejöjjön azzal a céllal, hogy megakadályozzák a X cég üzleté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 üzletet, mivel a törvényes kérelmek 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ég, amelyek mindegyike egyidejűleg támadást folytat. 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 tudják, 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 nem kell egyáltalán használni a számítógépet a támadás végrehajtásához.
SQL Injection Attack
Mi ez?
Az SQL injektálás( SQLI) támadás olyan kihasználás, amely kihasználja a rossz webes fejlesztési technikákat és általában a hibás adatbázis-biztonságot. 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 megakadályozható, ha egy webes alkalmazást megfelelően programoznak.
Az
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 futtathat egy lekérdezést, mint például a következő:
SELECT Felhasználóazonosító felhasználókból WHERE UserName = 'myuser' AND Password= 'mypass';
Megjegyzés: Az SQL lekérdezésben lévő karakterláncokat egyéni idézőjelekben kell elhelyezni, ezért jelenik meg a felhasználó beírt értékei köré.
Tehát a beírt felhasználói név( myuser) és a jelszó( mypass) kombinációja meg kell egyeznie a Felhasználók táblában szereplő bejegyzéssel annak érdekében, hogy a UserID visszaküldhessen. 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.
Így 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 Felhasználóazonosító felhasználókból WHERE UserName = '[felhasználó]' AND Password = '[pass]'
Első pillantásra ezúgy tűnhet, hogy egyszerű és logikus lépés 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 ezen a sablonon, akkor SQLI támadásra van hajlamos. Például, feltételezzük, hogy a "myuser'-" be van írva a felhasználói név mezőbe, és a "wrongpass" szerepel a jelszóban. A sablon lekérdezésében egyszerű helyettesítést használva a következőket kaptuk:
SELECT Felhasználóazonosító a felhasználóktól WHERE UserName = 'myuser' - 'ÉS jelszó =' wrongpass '
Ennek a kijelentésnek a kulcsa a két kötőjel( -),.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, mint:
SELECT Felhasználóazonosító felhasználókból WHERE UserName = 'myuser'
A szembetűnő 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 tudta, hogy "myuser" -ként tud bejelentkezni 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ó( amit 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 weboldalra 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áthatod, hogy a "youruser" -, "admin" - "vagy bármely más felhasználónév beírásával azonnal bejelentkezhetsz a webhelyre, anélkül, hogy tudnád a jelszót. 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ázist, amely lehetővé teszi a rekordok törlését, táblázatok hozzáadását / eltávolítását, új biztonsági számlák hozzáadását stb. Fontos megjegyezni, hogy bizonyos webes alkalmazásokra ez a fajta engedély szükségesnem teljesen rossz a teljes ellenőrzés.
Annak érdekében, hogy illusztrálja az ebben a helyzetben elvégezhető károkat, a fenti képen látható példát a felhasználói név mezőbe írja be: "Robert"; DROP TABLE Users; - ".Egyszerű helyettesítés után a hitelesítési lekérdezés:
SELECT Felhasználóazonosító felhasználókból WHERE UserName = 'Robert';DROP TABLE Felhasználók; - 'AND Password =' wrongpass '
Megjegyzés: az SQL lekérdezés pontosvesszője egy adott mondat vége és egy új utasítás kezdete.
Melyik az adatbázis végrehajtása:
SELECT Felhasználóazonosító felhasználókból WHERE UserName = 'Robert'
DROP TABLE Felhasználók
Így tettünk egy SQLI támadást a teljes felhasználói táblázat törléséhez.
Természetesen sokkal rosszabb, mivel a megengedett SQL engedélyek függvényében a támadó az értékeket, a dump táblákat( vagy az egész adatbázist) szövegfájlra változtathatja, új bejelentkezési fiókokat hozhat létre, vagy akár eltérhet a teljes adatbázis telepítéstől.
SQL injekciós támadás megakadályozása
Mint korábban 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íthatja az úgynevezett fertőtlenítés( vagy elkerülése).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.
Ha például egy "O'neil" keresést akarsz keresni egy adatbázisban, akkor nem lehet egyszerű helyettesítést alkalmazni, mert az O pontozás után megjelenő egyetlen idézet 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ű közegészségügyi 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. : / nem megfelelő :
VÁLASSZA Felhasználóazonosító felhasználókból WHERE UserName = 'myuser \' - 'ÉS jelszó =' wrongpass '
Mivel az egyedi idézet a myuser után megszököttérték), az adatbázis szó szerint keresni fogja a "myuser" - "UserName" nevét. 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 Felhasználók; / helytelen :
SELECT Felhasználóazonosító felhasználókból WHERE UserName = 'Robert \';DROP TABLE Felhasználók; - 'AND Password =' wrongpass '
Egyszerűen elhagyva az egyetlen idézetet Robert után mind a pontosvessző, mind a kötőjel a UserName keresési stringen belül található, így az adatbázis szó szerint keresni fog a "Robert";- "helyett a táblázat törlésének végrehajtása.
Összefoglaló
Amíg 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ások ellen irányuló, számos szabadon hozzáférhető "hacker-eszköz" ihletet.
A támadások bizonyos típusai, például a DDoS, nem könnyen elkerülhetők, 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.