Cross site scripting (XSS)

A Cross site scripting (XSS – eredetileg CSS-nek rövidítették, de ez a rövidítés ütközött a Cascading Style Sheet rövidítésével, ezért változtattak rajta.) a számítógépes sebezhetőség egy fajtája: egy rosszindulatú web-felhasználó olyan kódot illeszt egy weblapra, amit más felhasználó is lát. Például ilyen kód lehet a HTML kód vagy egy kliens oldali script. Ha egy támadó egy XSS sebezhetőséget felfedez, azt felhasználhatja arra, hogy a hozzáférési ellenőrzést kikerülje, például azzal, hogy a böngésző által kapott weblap nem az eredeti forrásból származik (de megjelenésében azonos lehet az eredetivel).

1. Történelem

Amikor a Netscape elsőként bevezette a JavaScript nyelvet, már ők is sejtették, hogy ha a webszerver végrehajtható kódot küld át a böngészőnek, akkor az biztonsági kockázatot rejt magában. A kulcsprobléma evvel az, hogy a felhasználó egyszerre több böngésző ablakot is megnyithat. Bizonyos esetekben az egyik weblapon található scriptnek meg kell adni azt a lehetőséget, hogy egy másik lapon vagy objektumban lévő adathoz hozzáférjen, ugyanakkor ezt a lehetőséget szigorúan tiltani kellene, mivel egy rosszindulatú Web-site ezen az úton érzékeny információkhoz férhet hozzá. Ezért bevezették az „azonos eredet” szabályát, vagyis azt, hogy a lapok és az objektumok közötti interakció mindaddig megengedett, amíg ezek a lapok/objektumok ugyanabból a domainből, ugyanarról a portról ugyanavval a protokollal jönnek. Így egy rosszindulatú web-site nem kaphat meg érzékeny adatokat egy másik böngésző-ablakból JavaScript segítségével.

Azóta hasonló hozzáférési szabályokat határoztak meg más böngészőkre és kliens-oldali script nyelvekre is, azért hogy a felhasználókat megvédjék a támadó web-site-októl. Általánosságban elmondható, hogy az XSS biztonsági lyuk a fenti szabály mellőzéséből adódik. Ha támadónak egy ügyes módszerrel sikerül egy másik domainhez tartozó weblapra rosszindulató programot (script) beszúrnia, akkor a magasabb szintű hozzáférési jogokkal érzékeny tartalmakhoz, sütikhez (cookies) és más objektumokhoz fér hozzá.

2. Az XSS eredete

Az Cross-site Scripting (azaz a site-ok közti scriptelés/programozás) nem pontosan írja le ezt a típusú sebezhetőséget. Marc Slemko, az egyik XSS úttörő szavai szerint: Nem a script írásáról és semmi esetre sem a site-ok közti dolgokról van itt szó. A nevet még akkor találtuk ki, amikor a problémát még nem értettük meg teljesen, de már megjelent az interneten. Higgyék el, kisebb gondunk is nagyobb volt annál, hogy jobb nevet találjunk.

A CSS rövidítést csak kezdetben használták, de ez egy sor más technikai fogalommal ütközött: Cascading Stlye Sheets, Content-scrambling system. Az XSS rövidítést talán Steve Champeon a Webmonkey-ban megjelent cikkében használta először: „XSS, Trust és Barney”. 2002-ben Steve a Bugtraq listán is javasolta az XSS rövidítés alkalmazását. A biztonsággal foglalkozó szakemberek ritka egyetértésben rögtön elfogadták ezt az alternatívát, és ma már alig használják a CSS rövidítést.

3. Az XSS típusai

Napjainkban héromfajta XSS-t különböztetünk meg. Ezeket 1., 2. és 3. típusúaknak nevezzük, de ezek a nevek nem általánosan elfogadottak, vagy szabványos nevek.

I. típusú XSS
Ezt a típusú XSS-t DOM-alapúnak vagy lokális XSS-nek is nevezik, és bár egyáltalán nem újkeletű, egy nemrég megjelent cikk nagyon pontosan írja le a jellemzőit( DOM-Based cross-site scripting). Az 1. típusú XSS sebezhetőségnél a probléma a lap kliens oldali scriptjében van. Például, ha egy JavaScript programnak egy URL paraméterre van szüksége, és ezt az információt felhasználva írja ki a HTML kódot a lapra és az információt nem kódolja HTML kódolás alkalmazásával, valószínűleg XSS lyuk fog létrejönni, mivel a leírt adatot a böngésző HTML-ként újra interpretálhatja, akár újabb kliens-oldali scripttel. A gyakorlatban az 1. típusú XSS sebezhetőség feltárása nagyon hasonlít a 2. típusúhoz (ld. lejjebb), egyetlen kivételtől eltekintve. Mivel az Internet Explorer a kliens-oldali scriptet a „lokális zónában” elhelyezett objektumként kezeli (például a kliens oldali hard diszken), ez a fajta, a lokális lapon lévő XSS egy távolban végrehajtható sebezhetőséget okoz. Például ha a támadó egy rosszindulatú website-ot üzemeltet, ami a kliens lokális rendszerén lévő, sebezhető lapra mutató linket tartalmaz, akkor egy scriptet lehet erre a lapra beszúrni, ami a felhasználó böngészőjének jogosultságával fog futni. Ez így a kliensoldali védelmet mellőzi, ellentétben a domainek közti korlátozással, ami normális esetben mellőzi az XSS sebezhetőséget.

II. típusú XSS
Ezt a típusú XSS lyukat nem-állandó vagy tükrözött sebezhetőségnek is hívják, és messze ez a legelterjedtebb fajta. Akkor lép fel, amikor a web-kliens által szolgáltatott adatot a szerver-oldali script azonnal felhasználja, azért hogy a kliensnek a (dinamikus) válaszlapot létrehozza. Ha ellenőrizetlen és HTML kódolás nélküli kliens-adat kerül be a szerverre, akkor így lehetővé válik, hogy a kliens-oldali kód a dinamikus lapba bekerüljön. Klasszikus példa erre a site keresőmotorja lehet: a keresett kifejezések közé HTML speciális karaktereket írnak be, és ha ezt nem kódolja a keresőmotor, akkor XSS lyuk keletkezhet.

Első pillanatre ez nem tűnhet komoly problémának, mert a felhasználó a saját lapjára szúrja be a kódot. Azonban egy másik felhasználót könnyen meggyőzhetünk arról (social engineering), hogy azt az URL-t használja, ami a rosszindulató kódot tartalmazza, és amihez a támadónak teljes hozzáférése van. Az emberi meggyőzés szükségessége miatt sok szakember nem veszi komolyan ezt a biztonsági lyukat (akárcsak az 1. típusút). Félreértések miatt gyakran minden XSS sebezhetőséget mellőznek, és gyakran a biztonságért felelős emberek között sincs egyetértés az XSS sebezhetőség fontosságának megítélésében.

III. Típusú XSS
Ezt a fajta XSS sebezhetőséget tárolt vagy állandó vagy másodrendű sebezhetőségnek nevezik, és ez teszi lehetővé a legerőteljesebb támadást. A 3. típusú XSS sebezhetőség akkor lép fel, ha a felhasználó által a web-alkalmazás felé továbbított adatait a szerver állandóan tárolja (adatbázisban, fájl rendszerben vagy más helyen), és később a felhasználóknak weblap formájában olvashatóvá teszi HTML kódolás nélkül. Klasszikus példa erre az online üzenet-felület, ahol a felhasználó HTML formátumú üzenetet postázhat más felhasználó részére. Ez a sebezhetőség sokkal jelentősebb a többi típusnál, mivel a támadó közvetlenül be tudja szúrni a scriptjét. Nagyon sok felhasználót érinthet anélkül, hogy emberi meggyőzésre lenne szükség, sőt a webalkalmazás XSS vírussal is megfertőzhető. A beszúrás számos módszerrel történhet, és a támadónak nem kell a web-alkalmazást használni ahhoz, hogy kihasználjon egy ilyen biztonsági lyukat. Bármely, web-alkalmazástól kapott adatot (elektronikus levél, rendszernapló, stb.), amit egy támadó is vezérelhet, kódolni kell, mielőtt egy dinamikus weblapnál felhasználjuk azokat, különben XSS sebezhetőséget eredményezhet.

4. A támadás menete

A támadónak mindhárom esetet másképp kell megközelítenie. Minden típushoz egy speciális támadási vektort mutatunk be a továbbiakban. (Az alábbi neveket a hálózatbiztonságban gyakran használt szerepek szerint osztpttuk ki.)

I. típusú támadás

1. Mallory Aliznak egy rosszindulattal megszerkesztett URL-t küld (elektronikus levél vagy más formában) Alíznak.
2. Alíz rákattint a linkre.
3. A rossz weblapon lévő JavaScript Alíz számítógépén egy sebezhető HTML lapot hoz létre.
4. Ez a sebezhető HTML lap olyan JavaScript kódot tartalmaz, ami Alíz számítógépnek lokális zónájában fut.
5. Mallory rosszindulatú scriptje Alíz jogosultságával futtathat paracsokat.

II. típusú támadás

1. Alíz gyakran látogat egy olyan website-ot, amit Bob kezel. Bob megengedi Alíznak, hogy felhasználói név/jelszó azonosítás után bejelentkezzen a gépre, és érzékeny információt – pl. számladatokat – tároljon ott.
2. Mallory észreveszi, hogy Bob websiteja nem-állandó XSS sebezhetőségtől szenved (2. típus).
3. Mallory egy URL-t állít össze, hogy ki tudja használni a sebezhetőséget, és ezt elküldi Alíznak elektronikus levélben. Úgy tesz, mintha Bob küldte volna a levelet (azaz elektronikus levelet hamisít).
4. Alíz meglátogatja a kérdéses URL-t, amit Mallory állított össze, miközben azt hiszi, hogy Bob website-jára lép be.
5. Az URL-be ágyazott rosszindulatú script, amit Alíz böngészője végrehajt, lefut. A script érzékeny információkat (bejelentkezési adatokat, számlaadatokat, stb) lop el, és azt Mallory weblapjára küldi, anélkül, hogy Alíz tudna róla.

III. típusú támadás

1. Bob egy olyan website-ot üzemeltet, ami megengedi a felhasználóknak, hogy üzeneteket és egyéb tartalmakat feltegyenek a többi látogató számára.
2. Mallory észreveszi, hogy a Bob website-ja 3. típusú XSS-sel sebezhető.
3. Mallory küld egy provokatív üzenetet, ami a többieket arra készteti, hogy megnézzék.
4. A küldött üzenet megtekintése közben felhasználói sütik és más személyes adatok jutnak el Malloryhoz, miközben a felhasználók ezt észre sem veszik.
5. Később Mallory más felhasználó nevében bejelentkezik a site-ra, üzeneteket postáz stb.
6. Az előbbi példák inkább általános támadási típusok, nem tartalmazzák az összes támadási vektor típust.

(Forrás: cert.hu)