A webalkalmazásokkal az a probléma, hogy nyíltan ki vannak téve internetfelhasználók milliárdjainak, akik közül sokan meg akarják majd törni a biztonsági intézkedéseket – bármilyen okból is.
Az internet kezdeti napjaiban az egyik leggyakoribb támadási módszer az egyszerű, egyszerű brute force volt. Általában a botok hajtották végre ezeket a támadásokat – vagy olyan személyek, akiknek sok szabadsága volt –, akik a felhasználónevek és jelszavak számtalan kombinációját próbálták ki, amíg megtalálták azt, amely hozzáférést biztosít a célalkalmazáshoz.
A jelszószabályoknak, a korlátozott bejelentkezési kísérleteknek és a captcháknak köszönhetően a brute force támadások már nem jelentenek veszélyt. A kiberbűnözők azonban szeretnek új támadásokat felfedezni és új típusú támadások végrehajtására használni. Réges-régen felfedezték, hogy az alkalmazások vagy weboldalak szövegmezői kihasználhatók váratlan szövegek beírásával – vagy beszúrásával –, amelyek arra kényszerítik az alkalmazást, hogy olyasmit tegyen, amit nem kellett volna. Ily módon az úgynevezett injekciós támadások a helyszínre kerültek.
Az injekciós támadások segítségével nem csak egy alkalmazásba lehet bejelentkezni a felhasználónév és jelszó ismerete nélkül, hanem személyes, bizalmas vagy érzékeny információk felfedésére, vagy akár egy teljes szerver eltérítésére is. Éppen ezért ezek a támadások nem csak a webalkalmazásokat fenyegetik, hanem azokat a felhasználókat is, akiknek az adatai ezekben az alkalmazásokban vannak, és a legrosszabb esetben más kapcsolódó alkalmazásokat és szolgáltatásokat is.
Tartalomjegyzék
Kódbefecskendezés
A kódbefecskendezés az injekciós támadások egyik leggyakoribb típusa. Ha a támadók ismerik a webalkalmazás által használt programozási nyelvet, keretrendszert, adatbázist vagy operációs rendszert, akkor szövegbeviteli mezőkön keresztül kódot szúrhatnak be, hogy arra kényszerítsék a webszervert, amit akarnak.
Az ilyen típusú befecskendezési támadások olyan alkalmazásokon lehetségesek, amelyeknél hiányzik a bemeneti adatok érvényesítése. Ha egy szövegbeviteli mezőben a felhasználók azt írhatják be, amit akarnak, akkor az alkalmazás potenciálisan kihasználható. E támadások megelőzése érdekében az alkalmazásnak annyit kell korlátoznia, amennyire csak tudja, hogy a bemeneti felhasználók beléphessenek.
Például korlátoznia kell a várt adatok mennyiségét, ellenőriznie kell az adatformátumot, mielőtt elfogadná, és korlátoznia kell a megengedett karakterkészletet.
A kódbefecskendezési sebezhetőségek könnyen megtalálhatók, csupán egy különböző típusú tartalommal rendelkező webalkalmazás szövegbevitelének tesztelésével. Amikor megtalálják a sebezhetőséget, közepesen nehéz kihasználni. Ha azonban a támadónak sikerül kihasználnia e biztonsági rések valamelyikét, a hatás a bizalmasság, az integritás, a rendelkezésre állás vagy az alkalmazás funkcióinak elvesztésével járhat.
SQL injekció
A kódbefecskendezéshez hasonlóan ez a támadás egy SQL-szkriptet – a legtöbb adatbázis által a lekérdezési műveletek végrehajtására használt nyelvet – beszúr egy szövegbeviteli mezőbe. A szkript elküldésre kerül 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 hajthat végre, például érzékeny adatokat közvetlenül az adatbázisból olvashat ki, módosíthatja vagy megsemmisítheti az adatbázis adatait, vagy adminisztrátori műveleteket hajthat végre az adatbázison.
A PHP és az ASP alkalmazások hajlamosak az SQL injekciós támadásokra a régebbi funkcionális interfészek miatt. A J2EE és az ASP.Net alkalmazások általában jobban védettek ezekkel a támadásokkal szemben. Ha egy SQL-befecskendezési sebezhetőséget találnak – és könnyen megtalálhatók is – a potenciális támadások mértékének csak a támadó készsége és fantáziája szab határt. Így az SQL injekciós támadás hatása kétségtelenül magas.
Parancs injekció
Ezek a támadások is lehetségesek, főként az elégtelen bemeneti ellenőrzés miatt. Abban különböznek a kódbefecskendező támadásoktól, hogy a támadó programozási kódrészletek vagy parancsfájlok helyett rendszerparancsokat szúr be. Ezért a hackernek nem kell ismernie azt a programozási nyelvet, amelyen az alkalmazás alapul, vagy az adatbázis által használt nyelvet. De ismerniük kell a tárhelyszerver által használt operációs rendszert.
A beszúrt rendszerparancsokat a gazdagép operációs rendszer az alkalmazás jogosultságaival hajtja végre, ami többek között lehetővé teheti a szerveren található tetszőleges fájlok tartalmának feltárását, egy szerver könyvtárszerkezetének megjelenítését, felhasználói jelszavak megváltoztatását .
Ezeket a támadásokat a rendszergazda megakadályozhatja a kiszolgálón futó webalkalmazások rendszer-hozzáférési szintjének korlátozásával.
Webhelyek közötti szkriptelés
Amikor egy alkalmazás beszúr egy felhasználótól származó bemenetet az általa generált kimenetbe, anélkül, hogy azt érvényesítené vagy kódolná, lehetőséget ad a támadónak, hogy rosszindulatú kódot küldjön egy másik végfelhasználónak. A Cross-Site Scripting (XSS) támadások kihasználják ezeket a lehetőségeket, hogy rosszindulatú szkripteket fecskendezzenek be megbízható webhelyekre, amelyeket végül elküldenek az alkalmazás többi felhasználójának, akik a támadó áldozataivá válnak.
Az áldozatok böngészője anélkül hajtja végre a rosszindulatú szkriptet, hogy tudná, hogy nem szabad megbízni benne. Ezért a böngésző lehetővé teszi számára, hogy hozzáférjen a munkamenet-tokenekhez, cookie-khoz vagy a böngésző által tárolt érzékeny információkhoz. Ha megfelelően van programozva, a szkriptek akár egy HTML-fájl tartalmát is átírhatják.
Az XSS-támadások általában két kategóriába sorolhatók: tárolt és tükrözött.
Tárolt XSS támadások esetén a rosszindulatú szkript állandóan a célszerveren, egy üzenetfórumon, egy adatbázisban, egy látogatói naplóban stb. tartózkodik. Az áldozat akkor kapja meg, amikor a böngészője lekéri a tárolt információkat. A tükröződő XSS-támadásokban a rosszindulatú szkript olyan válaszban jelenik meg, amely tartalmazza a kiszolgálónak küldött bemenetet. Ez lehet például hibaüzenet vagy keresési eredmény.
XPath injekció
Ez a fajta támadás akkor lehetséges, ha egy webalkalmazás a felhasználó által biztosított információkat használja fel XPath-lekérdezés létrehozásához XML adatokhoz. Ezek a támadások működése hasonló az SQL injekcióhoz: a támadók hibásan formázott információkat küldenek az alkalmazásnak, hogy megtudják, hogyan épül fel az XML-adatok, majd ismét támadnak, hogy hozzáférjenek az adatokhoz.
Az XPath egy szabványos nyelv, amellyel az SQL-hez hasonlóan megadhatja a keresni kívánt attribútumokat. Az XML-adatok lekérdezéséhez a webalkalmazások felhasználói bevitellel állítanak be egy mintát, amelynek meg kell egyeznie az adatokkal. Rosszul formázott bemenet elküldésével a minta olyan műveletté alakulhat, amelyet a támadó alkalmazni szeretne az adatokra.
Az SQL-lel ellentétben az XPathban nincsenek különböző verziók. Ez azt jelenti, hogy az XPath injekció bármilyen XML-adatokat használó webalkalmazáson elvégezhető, a megvalósítástól függetlenül. Ez azt is jelenti, hogy a támadás automatizálható; ezért az SQL injekciótól eltérően tetszőleges számú cél ellenében megvan a lehetőség.
Mail parancs injekció
Ez a támadási módszer használható olyan e-mail szerverek és alkalmazások kihasználására, amelyek IMAP- vagy SMTP-utasításokat készítenek nem megfelelően érvényesített felhasználói bevitellel. Esetenként az IMAP- és SMTP-kiszolgálók nem rendelkeznek erős védelemmel a támadások ellen, mint a legtöbb webszerver esetében, és ezért jobban kihasználhatók. A levelezőszerveren keresztül belépve a támadók megkerülhetik a korlátozásokat, például a captchákat, a korlátozott számú kérést stb.
Az SMTP-kiszolgáló kihasználásához a támadóknak érvényes e-mail fiókra van szükségük ahhoz, hogy üzeneteket küldhessenek beadott parancsokkal. Ha a szerver sebezhető, akkor válaszol a támadók kéréseire, lehetővé téve számukra például, hogy felülbírálják a szerver korlátozásait, és a szolgáltatásait spam küldésére használják.
Az IMAP-injektálás főként webmail alkalmazásokon valósítható meg, kihasználva az üzenetolvasási funkciót. Ezekben az esetekben a támadást úgy lehet végrehajtani, hogy a webböngésző címsorába egyszerűen beír egy URL-t a beinjektált parancsokkal.
CRLF injekció
A kocsivisszaadási és soremelési karakterek – a CRLF néven ismert kombináció – beszúrása a webes űrlapok beviteli mezőibe a CRLF injekciónak nevezett támadási módszert képviseli. Ezek a láthatatlan karakterek egy sor vagy egy parancs végét jelzik számos hagyományos internetes protokollban, mint például a HTTP, MIME vagy NNTP.
Például egy CRLF beillesztése egy HTTP-kérelembe, amelyet bizonyos HTML-kód követ, egyéni weboldalakat küldhet egy webhely látogatóinak.
Ez a támadás olyan sebezhető webalkalmazásokon hajtható végre, amelyek nem alkalmazzák a megfelelő szűrést a felhasználói bevitelre. Ez a sérülékenység megnyitja az ajtót más típusú injekciós támadások előtt, mint például az XSS és a kódbefecskendezés, és egy webhely eltérítéséből is származhat.
Host Header injekció
A sok webhelyet vagy webalkalmazást kiszolgáló szervereken a gazdagép fejléc szükségessé válik annak meghatározásához, hogy a rezidens webhelyek vagy webalkalmazások – mindegyik virtuális gazdagépként ismert – melyik dolgozzon fel egy bejövő kérést. A fejléc értéke közli a szerverrel, hogy melyik virtuális gazdagépnek küldjön kérést. Amikor a szerver érvénytelen gazdagép fejlécet kap, általában továbbítja azt a lista első virtuális gazdagépének. Ez egy biztonsági rést jelent, amelyet a támadók arra használhatnak, hogy tetszőleges hosztfejléceket küldjenek a kiszolgáló első virtuális gazdagépének.
A gazdagép fejlécének manipulálása általában PHP-alkalmazásokhoz kapcsolódik, bár más webfejlesztési technológiákkal is elvégezhető. A gazdagép-fejléc-támadások más típusú támadások, például a web-gyorsítótár-mérgezések elősegítőiként működnek. Következményei lehetnek a támadók érzékeny műveleteinek végrehajtása, például a jelszó visszaállítása.
LDAP injekció
Az LDAP egy protokoll, amelyet az erőforrások (eszközök, fájlok, más felhasználók) hálózaton belüli keresésének megkönnyítésére terveztek. Nagyon hasznos az intraneteknél, és ha egyszeri bejelentkezési rendszer részeként használjuk, akkor felhasználónevek és jelszavak tárolására is használható. Az LDAP-lekérdezések speciális vezérlőkaraktereket használnak, amelyek befolyásolják a vezérlést. A támadók potenciálisan megváltoztathatják az LDAP-lekérdezések tervezett viselkedését, ha vezérlőkaraktereket tudnak beilleszteni abba.
Az LDAP injekciós támadásokat lehetővé tévő gyökér probléma ismét a nem megfelelően érvényesített felhasználói bevitel. Ha a felhasználó által egy alkalmazásnak küldött szöveget egy LDAP-lekérdezés részeként használják anélkül, hogy megtisztítanák azt, akkor a lekérdezés a végén lekérheti az összes felhasználó listáját és megjelenítheti azt a támadónak, csak egy csillag használatával.
a megfelelő helyen egy bemeneti karakterláncon belül.
Injekciós támadások megelőzése
Amint ebben a cikkben láttuk, minden injekciós támadás olyan szerverek és alkalmazások felé irányul, amelyek bármely internetfelhasználó számára nyílt hozzáféréssel rendelkeznek. A támadások megelőzésének felelőssége megoszlik az alkalmazásfejlesztők és a szerveradminisztrátorok 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 módszereket a felhasználói bevitel kockázatmegelőzési célból történő megtisztítására. A szerveradminisztrátoroknak rendszeres időközönként ellenőrizniük kell rendszereiket, hogy észleljék a sebezhetőségeket, és mielőbb kijavítsák azokat. Számos lehetőség van ezeknek az ellenőrzéseknek a végrehajtására, akár igény szerint, akár automatikusan.