9 népszerű webes alkalmazás-befecskendezési támadás típus

A webes alkalmazások problémája az, hogy nyíltan ki vannak téve az internetek milliárdjainak, akik közül sokan meg akarja szakítani a biztonsági intézkedéseit – bármilyen okból is.


Az internet korai napjaiban az egyik leggyakoribb támadási módszer az alapvető, egyszerű brutális erő volt. A botok általában ezeket a támadásokat hajtották végre – vagy sok időt vesz igénybe -, akik zillionnyi felhasználói név és jelszó kombinációt próbáltak ki, amíg nem találtak egyet, amely hozzáférést biztosítana a cél alkalmazáshoz..

A brutális erőszakos támadások már nem jelentenek fenyegetést a jelszavas házirendek, a korlátozott bejelentkezési kísérletek és a captchasoknak köszönhetően. A számítógépes bűnözők azonban szeretnek új kizsákmányolásokat fedezni és új típusú támadások végrehajtására használni őket. Régóta felfedezték, hogy az alkalmazások vagy weboldalak szövegmezői kihasználhatók azáltal, hogy váratlan szöveget írnak be, vagy befecskendeznek, ami arra kényszeríti az alkalmazást, hogy tegyen valamit, amit nem kellett volna tennie. Ilyen módon az úgynevezett injekciós támadások léptek be a helyszínre.

Az injekciós támadások nemcsak az alkalmazásba való bejelentkezéshez használhatók felhasználónév és jelszó ismerete nélkül, hanem magán-, bizalmas vagy érzékeny információk felfedésére vagy akár egy teljes szerver eltérítésére is. Ezért ezek a támadások nemcsak veszélyt jelentenek a webes alkalmazásokra, hanem a felhasználókat is, akiknek adatai ezen alkalmazásokon találhatók, és a legrosszabb esetben más kapcsolódó alkalmazásokra és szolgáltatásokra is..

Kód injekció

A kódinjekció az injekciós támadások egyik leggyakoribb típusa. Ha a támadók ismerik a webes alkalmazás által használt programozási nyelvet, a keretet, az adatbázist vagy az operációs rendszert, akkor beírhatnak kódot szöveges beviteli mezőkön keresztül, hogy a webszervert kényszerítsék arra, amit akarnak.

Az ilyen típusú befecskendezési támadások olyan alkalmazásokon lehetségesek, amelyeknél nincs bemeneti adatok érvényesítése. Ha egy szövegbeviteli mező lehetővé teszi a felhasználók számára, hogy bármit megadhassanak, akkor az alkalmazás potenciálisan kihasználható. Ezeknek a támadásoknak a megelőzése érdekében az alkalmazásnak annyit kell korlátoznia, amennyire csak lehetséges a bemeneti felhasználók belépése.

Például korlátoznia kell a várt adatok mennyiségét, ellenőriznie kell az adat formátumát, mielőtt elfogadná, és korlátoznia kell az engedélyezett karakterek halmazát..

A kódbeviteli sérülékenységeket könnyű megtalálni, csupán egy különféle típusú tartalommal rendelkező webalkalmazás szövegbevitelének tesztelésével. Ha megtalálják, a sebezhetőségeket mérsékelten nehéz kiaknázni. De amikor a támadónak sikerül kiaknáznia ezen sebezhetőségek egyikét, a hatás magában foglalhatja a bizalmasság, az integritás, a rendelkezésre állás vagy az alkalmazás funkcionalitásának elvesztését..

SQL injekció

A kódbevitelhez hasonló módon ez a támadás beilleszt egy SQL szkriptet – a legtöbb adatbázis által használt lekérdezési műveletek elvégzéséhez használt nyelvet – a szövegbeviteli mezőbe. A parancsfájlt elküldik az alkalmazásnak, amely közvetlenül az adatbázisában hajtja végre. Ennek eredményeként a támadó áthaladhat egy bejelentkezési képernyőn, vagy veszélyesebb dolgokat végezhet, például érzékeny adatokat olvashat közvetlenül az adatbázisból, módosíthatja vagy megsemmisítheti az adatbázis adatait, vagy végrehajthat az adatbázis adminisztrátori műveleteit..

A PHP és az ASP alkalmazások régebbi funkcionális interfészeik miatt hajlamosak az SQL injektálási támadásokra. A J2EE és az ASP.Net alkalmazások általában jobban védettek ezekkel a támadásokkal szemben. Ha egy SQL-befecskendezés során sebezhetőséget találnak – és könnyen megtalálhatók -, a lehetséges támadások mértékét csak a támadó képessége és képzelete korlátozza. Így egy SQL injekciós támadás hatása kétségtelenül magas.

Parancs injekció

Ezek a támadások szintén lehetségesek, elsősorban a bemeneti adatok elégtelen validálása miatt. Ezek abban különböznek a kódinjekciós támadásoktól, hogy a támadó programozási kód vagy szkript helyett rendszerparancsokat vezet be. Ezért a hackereknek nem kell ismerniük az alkalmazás alapjául szolgáló programozási nyelvet vagy az adatbázis által használt nyelvet. De tudniuk kell a host kiszolgáló által használt operációs rendszert.

A beillesztett rendszerparancsokat a gazda operációs rendszer az alkalmazás privilégiumaival hajtja végre, amelyek lehetővé teszik a kiszolgálón lévő tetszőleges fájlok tartalmának feltárását, a kiszolgáló könyvtárstruktúrájának megjelenítését, többek között a felhasználói jelszavak megváltoztatását..

Ezeket a támadásokat egy rendszergazda megakadályozhatja, ha korlátozza a kiszolgálón futó webes alkalmazások rendszerhozzáférési szintjét.

Webhelyek közötti szkriptek

Ha egy alkalmazás beilleszt egy felhasználót a létrehozott kimenetbe, anélkül, hogy validálná vagy kódolná, lehetőséget ad a támadónak, hogy rosszindulatú kódot küldjön egy másik végfelhasználóra. A webhelyek közötti szkriptelés (XSS) támadások megragadják ezeket a lehetőségeket, hogy rosszindulatú szkripteket adjanak be a megbízható webhelyekre, és végül elküldik az alkalmazás más felhasználóinak, akik a támadó áldozatává válnak..

Az áldozatok böngészője végrehajtja a rosszindulatú szkriptet anélkül, hogy tudná, hogy nem szabad megbízni benne. Ezért a böngésző engedi hozzáférni a munkamenet-tokenekhez, a sütikhez vagy a böngésző által tárolt érzékeny információkhoz. Megfelelően programozva a szkriptek akár egy HTML fájl tartalmát is átírhatják.

Az XSS támadásokat általában két különböző kategóriába lehet osztani: tárolt és visszavert.

Ban ben memorizált XSS támadások esetén a rosszindulatú szkript állandóan a célkiszolgálón, üzenetfórumban, adatbázisban, látogatói naplóban stb. Található. Az áldozat akkor kapja meg, amikor böngészője kéri a tárolt információkat. Ban ben tükrözi XSS támadások esetén a rosszindulatú szkript egy válaszban tükröződik, amely tartalmazza a kiszolgálóra küldött bemenetet. Ez lehet például hibaüzenet vagy keresési eredmény.

XPath injekció

Ez a támadás akkor lehetséges, amikor egy webes alkalmazás a felhasználó által szolgáltatott információkat használja az XPath lekérdezés elkészítéséhez az XML adatokhoz. A támadás működése hasonló az SQL-befecskendezéshez: a támadók rosszul formázott információkat küldnek az alkalmazásnak, hogy megtudják, hogyan épül fel az XML-adatok, majd újra támadnak, hogy hozzáférjenek az adatokhoz..

Az XPath egy szabványos nyelv, amellyel az SQL-hez hasonlóan megadhatja a megtalálni kívánt attribútumokat. Az XML-adatok lekérdezéséhez a webes alkalmazások felhasználói bevitellel állítják be az adatoknak meg kell egyezniük a mintát. A hibás bemenet küldésével a minta olyan műveletgé válhat, amelyet a támadó alkalmazni kíván az adatokra.

Ellentétben azzal, ami az SQL-vel történik, az XPath-ban nincs különféle verzió. Ez azt jelenti, hogy az XPath injekciót bármilyen webalkalmazásban meg lehet tenni, amely XML-adatokat használ, függetlenül a megvalósítástól. Ez azt is jelenti, hogy a támadás automatizálható; ezért az SQL-befecskendezéssel ellentétben tetszőleges számú célkitűzés ellen lőhet.

Levélparancs injekció

Ez a támadási módszer felhasználható e-mail szerverek és alkalmazások kiépítésére, amelyek IMAP vagy SMTP utasításokat építenek helytelenül validált felhasználói bemenettel. Időnként az IMAP és az SMTP szerverek nem rendelkeznek erős védelemmel a támadások ellen, mint ez a legtöbb webszerver esetében lenne, és ezért hasznosabbak lehetnek. E-mail szerveren keresztül belépve a támadók megkerülhetik az olyan korlátozásokat, mint például captchas, korlátozott számú kérés stb.

Az SMTP-kiszolgáló kihasználásához a támadóknak érvényes e-mail fiókra van szükségük, hogy üzeneteket küldjenek befecskendezett parancsokkal. Ha a szerver sebezhető, akkor válaszol a támadók kéréseire, lehetővé téve számukra például a szerverkorlátozások felülbírálását és a szolgáltatásai spam küldését..

Az IMAP-injektálást elsősorban webmail-alkalmazásokon lehet elvégezni, az üzenetolvasási funkció kihasználásával. Ezekben az esetekben a támadást úgy lehet végrehajtani, hogy egyszerűen beír egy URL-t a böngésző címsorába a befecskendezett parancsokkal.

CRLF injekció

A kocsi visszatérési és a sor betáplálási karakterek beillesztése – a CRLF néven ismert kombináció – a webes formátumú beviteli mezőkbe a CRLF injekciónak nevezett támadási módszert képviseli. Ezek a láthatatlan karakterek a sor vagy a parancs végét jelzik sok hagyományos internetes protokollban, például a HTTP, a MIME vagy az NNTP.

Például egy CRLF beillesztése egy HTTP-kérelembe, majd egy bizonyos HTML-kódot követve, egyedi weboldalakat küldhet egy weboldal látogatói számára..

Ezt a támadást olyan veszélyeztetett webes alkalmazásokon lehet végrehajtani, amelyek nem alkalmazzák a megfelelő szűrést a felhasználói bemenetre. Ez a sérülékenység megnyitja az ajtót az egyéb típusú befecskendezési támadások, például az XSS és a kódinjekciók számára, és ennek következménye lehet egy eltérített webhely is..

Befogadás a fejlécbe

A sok webhelyet vagy webes alkalmazást üzemeltető szervereknél a host fejlécére lesz szükség annak meghatározásához, hogy a rezidens webhelyek vagy webes alkalmazások közül melyeket virtuális gazdagépnek nevezzék, és amelyek feldolgozzák a bejövő kérelmet. A fejléc értéke megmondja a szervernek, hogy melyik virtuális gazdagép küldje el a kérelmet. Amikor a szerver érvénytelen gazdafejlécet kap, általában átadja azt a lista első virtuális gazdagépének. Ez egy biztonsági rést jelent, amelyet a támadók felhasználhatnak tetszőleges gazdafejlécek küldésére a kiszolgáló első virtuális gazdagépére.

A host fejléc manipulálása általában a PHP alkalmazásokhoz kapcsolódik, bár megtehető más webfejlesztési technológiákkal is. A gazdagépes támadások lehetővé teszik a támadások más típusait, például a web-gyorsítótár mérgezését. Ennek következményei lehetnek a támadók által végrehajtott érzékeny műveletek, például a jelszó visszaállítása.

LDAP injekció

Az LDAP egy olyan protokoll, amely megkönnyíti az erőforrások (eszközök, fájlok, más felhasználók) keresését a hálózatban. Nagyon hasznos az intraneteknél, és ha egyszeri bejelentkezési rendszer részeként használják, felhasználható felhasználónevek és jelszavak tárolására. Az LDAP lekérdezések olyan speciális vezérlőkarakterek használatával járnak, amelyek befolyásolják az ellenőrzést. A támadók megváltoztathatják az LDAP-lekérdezés tervezett viselkedését, ha vezérlőkaraktereket illeszt be.

Ismét az a gyökérprobléma, amely lehetővé teszi az LDAP befecskendezés támadásait, a felhasználói bevitel helytelenül validált. Ha a felhasználó által az alkalmazáshoz elküldött szöveget egy LDAP lekérdezés részeként használják fel anélkül, hogy fertőtlenítenék, akkor a lekérdezés a jobb oldalon lévő csillag (*) használatával végül lekérheti az összes felhasználó listáját és megmutathatja azt egy támadónak. helyezze be egy bemeneti karakterláncba.

Az injekciós támadások megelőzése

Mint a cikkből láttuk, az összes befecskendező támadás olyan kiszolgálók és alkalmazások felé irányul, amelyek hozzáférése bármilyen internetes felhasználó számára elérhető. Az ilyen támadások megelőzésének felelőssége megoszlik az alkalmazásfejlesztők és a kiszolgálói rendszergazdák között.

Az alkalmazásfejlesztőknek ismerniük kell a felhasználói bevitel helytelen érvényesítésével járó kockázatokat, és meg kell tanulniuk a bevált gyakorlatokat a felhasználói bemenetek kockázatmegelőzési célokból történő tisztításához. A kiszolgáló rendszergazdáinak rendszeresen ellenőrizniük kell rendszereiket a sérülékenységek felismerése és a lehető leghamarabb kijavításuk céljából. Számos lehetőség van ezen ellenőrzések elvégzésére, akár igény szerint, akár automatikusan.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map