Cross-Site Scripting (XSS)

A cross-site scripting – más néven XSS – egy olyan sebezhetőség, amely képes pusztítást végezni az alkalmazásokban és a webhelyeken. Az XSS annyira elterjedt és potenciálisan káros, hogy továbbra is szerepel az Open Web Application Security Project (OWASP) top 10 sebezhetőségi listáján.

Valójában a Cross-Site Scripting a 2014 óta leggyakrabban felfedezett sebezhetőség, és 2019-ben továbbra is a bejelentett sebezhetőségek Top 3-ban szerepel.

Egyes esetekben a böngészőoldali szkript is bevezetheti ezt a sebezhetőséget, amely lehetővé teszi a támadó számára, hogy kihasználja azt anélkül, hogy a célfelhasználó kérést intézne a webes alkalmazáshoz.

A támadók az XSS-t úgy használják ki, hogy rosszindulatú kódot készítenek, amelyet egy másik felhasználóhoz továbbítanak, majd a gyanútlan böngésző végrehajtja. Mivel a szkript leggyakrabban a webalkalmazás válaszának tartalmában szerepel, végrehajtásra kerül, és ugyanolyan hozzáféréssel rendelkezik, mintha a szkript legitim lenne. Hozzáférhet a munkamenet-tokenekhez, a cookie-khoz, sőt, a böngésző által az adott webhelyen elérhető bizalmas vagy érzékeny információkhoz is, sőt, akár a HTML-oldal tartalmát is átírhatja.

Reflektált XSS-támadások

A reflektált XSS-támadásokban a rosszindulatú szkriptet egy HTTP-kérelembe injektálják (általában a felhasználónak megadott, kifejezetten erre a célra kialakított linkkel). Legegyszerűbb változataként olyan bemeneti paramétereket használ a HTTP-kérelemben, amelyek könnyen manipulálhatók a kártékony szkript tartalmának beépítésére. A rosszindulatú szkript ezután egy HTTP-válaszban tükröződik a kiszolgálóról, és végrehajtódik az áldozat böngészőjében.

Ez esetben úgy viselkedik, mint egy tárolt XSS, anélkül, hogy ténylegesen rosszindulatú adatokat tárolna a kiszolgálón.

Itt egy példa a visszavert XSS-támadásra:

Tegyük fel, hogy a example.com/profile tartalmaz egy név paramétert. A kérés URL címe így nézne ki: https://example.com/profile?user=Tammy. E bemenet alapján a webalkalmazás így az oldal tetején a “Hi Tammy” felirattal válaszolna. Ha a paraméterek validálása nem történik meg annak biztosítása érdekében, hogy csak a várt adatokat tartalmazza, a támadó ráveheti a felhasználót, hogy az URL egy rosszindulatú változatát látogassa meg, például így: https://example.com/profile?user<script>some_malicious_code</script>.

Amikor a válasz elküldésre kerül a böngészőnek, az tartalmazza ezt a rosszindulatú szkriptet, amely ezután végrehajtódik a böngészőben, valószínűleg anélkül, hogy a felhasználó tudna róla. Ez egy példa a reflektált XSS-támadásra, mivel a rosszindulatú kód azonnal “visszatükröződik” a kérést végző felhasználóra.

Tárolt XSS-támadások

A tárolt vagy tartós XSS-támadásnak nevezett esetben a rosszindulatú tartalom közvetlenül, a kiszolgáló válaszával együtt kerül átadásra, amikor a felhasználó betölt egy weboldalt. Így a tartalom már a weboldal adatbázisában tárolódik (innen az ilyen támadások elnevezése). A felhasználók ezután egyszerűen belépnek a feltört weboldalra, és áldozatul esnek az ilyen támadásoknak.

Minden egyes felhasználó, aki megnyit egy ilyen veszélyeztetett weboldalt, így ki van téve annak a veszélynek, hogy személyes adatait ellopják, ezért ez tekinthető az XSS-támadás legveszélyesebb típusának.

De hogyan kerül a rosszindulatú tartalom egyáltalán az adatbázisba? A legtöbb esetben olyan védtelen weboldali űrlapokon keresztül kerül be, amelyekben a felhasználói bemenet nincs megfelelően validálva és szanálva. Ha a hacker által bevitt adatok nincsenek validálva mind a kliens-, mind a szerveroldalon, akkor azok elmentésre kerülnek az adatbázisban. Ilyen bemenet lehet például a megjegyzés szöveges terület, a hozzászólás szövegszerkesztője, a személyes adatok szerkesztője vagy más űrlapok.

Ha egy támadónak sikerül rosszindulatú tartalmat küldenie a kiszolgálónak, és ez a tartalom szűretlenül megjelenik egy weboldalon, minden felhasználó potenciális áldozattá válik.A tárolt XSS-támadások általános ellenszere az alkalmazás front- és backendjén egyaránt a bemenet szanálása. A szanitizálás az adatok érvényesítésének és a speciális karakterek kikerülésének vagy teljes kiszűrésének kombinációját foglalja magában, és a webes és JavaScript-biztonság általános legjobb gyakorlata.

DOM-alapú XSS-támadások

A dokumentumobjektum-modell (DOM) egy olyan interfész, amely lehetővé teszi az alkalmazások számára a weblap szerkezetének, tartalmának és stílusának olvasását és manipulálását. A DOM-alapú XSS-támadás során a sebezhetőség a böngészőoldali szkriptkódban rejlik, és mindenféle szerverinterakció nélkül kihasználható, módosítva a gyanútlan áldozat böngészőjének környezetét.

Néha a DOM-alapú XSS-támadások hasonlítanak a reflektált támadásokhoz. A reflektált XSS-támadás fenti példája ebben az esetben egyetlen feltételezéssel alkalmazható: A webes alkalmazás közvetlenül egy lekérdezési karakterláncból olvassa az adatokat.

Tegyük fel, hogy az alkalmazás a “név” lekérdezési paramétert használja arra, hogy azonnal megjelenítse a felhasználó nevét a képernyőn, miközben az oldal többi részének betöltésére vár. Megfelelő validálás nélkül ez ugyanolyan eredményt hozhat, mint a reflektált támadás, ha a hackernek sikerül rávennie az áldozatot egy gyanús link megnyitására.

A tárolt XSS-hez hasonlóan a reflektált és DOM-alapú támadások megelőzése érdekében a fejlesztőknek adatérvényesítést kell végrehajtaniuk, és kerülniük kell a nyers felhasználói bemenet megjelenítését, a szerverrel való kommunikáció megléte vagy hiánya ellenére.

Melyek a Cross-site Scripting támadás vektorai?

Számos vektor van, amelyeket általában XSS-támadásokban használnak:

• <script> tag: A script tag külső JavaScript kódra való hivatkozásra használható, így ez a legegyszerűbb XSS pont. A támadók a rosszindulatú kódot a script tagbe is beágyazhatják.
• JavaScript események: A támadók által használt másik népszerű XSS-vektor, az eseményattribútumok számos tagben alkalmazhatók. Ilyen attribútumok például az “onerror” és az “onload”.
• <body> tag: Az eseményattribútumok a szkript forrása is lehetnek, ha a “body” címkén keresztül adják meg őket.
• <img> tag:
• <iframe> tag: Különösen hatékony adathalász-támadások esetén, ez a vektor lehetővé teszi az XSS-támadás során egy másik HTML-oldal beágyazását az aktuális oldalba.
• <input> tag: Egyes böngészők lehetővé teszik a manipulációt ezen a vektoron keresztül, amely egy szkript beágyazására használható.
• <link> tag: Ez a tag tartalmazhat egy szkriptet, a külső stíluslapokra való hivatkozás szokásos használata helyett.
• <table> tag: Ahol a háttér attribútum normális esetben egy képre utal, ez a tag kompromittálható, hogy a sértő szkriptre utaljon.
• <div> tag: Ez a tag szintén tartalmaz háttérhivatkozást, és a <table> címkéhez hasonlóan használható egy szkriptre való hivatkozásra.
• <object> tag: Ezzel a címkével külső webhelyről származó szkripteket lehet bevonni.

Míg vannak más vektorok is, amelyeket az XSS-támadók az információk ellopására és a webhelyek kompromittálására használnak, ezek a leggyakrabban használt módszerek. A fejlesztőknek be kell tartaniuk a megfelelő menekülési és szanitizálási gyakorlatokat az ilyen támadások elleni védekezéshez.

A támadótól és annak rosszindulatú szándékától függően az XSS-támadások különböző hatásokat eredményezhetnek, többek között:

• a felhasználó munkamenetének eltérítése, a hitelesítő adatok felhasználása más webhelyek eléréséhez vagy a felhasználó nem kívánt webhelyekre való átirányítása,
• a webhely oldalainak megváltoztatása vagy szakaszok beillesztése egy weboldalba,
• szkriptek végrehajtása érzékeny információk kinyerésére a cookie-kból vagy adatbázisokból,
• ha az áldozat rendszergazdai jogokkal rendelkezik, a támadás kiterjedhet a szerveroldalra, további kárt okozva vagy további érzékeny információk kinyerésével.

A kritikus webalkalmazások XSS sebezhetőségének tesztelésének legfontosabb lépései a következők:

• kódszkennelő eszköz használata a sebezhetőségek felderítésére, amely lehetővé teszi a kód javítását a fejlesztési folyamat során,
• a potenciális sebezhetőségeket alaposan és gyorsan feltáró automatizált tesztelési funkciók megvalósítása.

Tegyük fel, hogy az exmple.com/profile tartalmaz egy név paramétert. A kérés URL címe így nézne ki: https://example.com/profile?user=Tammy. A webalkalmazás ezen input alapján az oldal tetején a “Hi Tammy”-vel válaszol.

Ha a felhasználói paramétert nem ellenőrzik, hogy csak a várt adatokat tartalmazza, a támadó ráveheti a felhasználót, hogy látogasson el az URL rosszindulatú változatára, amely így néz ki:
https://example.com/profile?user<script>some_malicious_code</script>.
A válasz elküldésekor a böngészőnek az tartalmazza ezt a rosszindulatú szkriptet, amely aztán a böngészőben végrehajtódik, valószínűleg a felhasználó tudta nélkül. Ez egy példa a reflektált XSS-támadásra. A rosszindulatú kód azonnal “visszatükröződik” a kérést küldő felhasználónak.

• Oktatás és tudatosság: Győződjön meg arról, hogy minden fejlesztő, webhelytervező és minőségbiztosítási csapat tisztában van a hackerek által a sebezhetőségek kihasználására használt módszerekkel, és adjon iránymutatást és legjobb gyakorlatokat a kódoláshoz. Ez magában foglalja az alkalmazási környezet (JavaScript, HTML stb.) megfelelő escaping/kódolási technikáit.
• Sanitize input: Akár belső weboldalakról, akár nyilvános webhelyekről van szó, soha ne bízzon a felhasználói bemeneti adatok érvényességében. Szűrje át és validálja az adatmezőket, különösen, ha azok HTML-kimenetként szerepelnek majd.
• Ellenőrizze a kódot: Alkalmazzon olyan szoftvert, amely a kódot a sebezhetőségek, többek között a cross-site scripting szempontjából vizsgálja, hogy biztosítsa a legjobb gyakorlatok betartását, és minimalizálja az XSS és más, az OWASP listáján szereplő sebezhetőségeknek való kitettséget.
• Tartalombiztonsági szabályzat: A Content Security Policy (CSP) segítségével meghatározza, hogy mit tehet egy weboldal, és ezzel csökkenti az XSS-támadás kockázatát. A CSP használatával az XSS teljesen blokkolható (az összes soron belüli szkript blokkolásával), vagy sokkal alacsonyabb kockázatúvá csökkenthető.

AzOWASP egy átfogó puskával további útmutatást nyújt az XSS sebezhetőség megelőzéséhez.