Üdvözöljük! arrow Ismertetők arrow Incidensek, sebezhetőségek arrow Cross site scripting (XSS)
Cross site scripting (XSS)

Cross site scripting (XSS)

Az XSS a számítógépes sebezhetőség egy fajtája, amely tipikusan web alkalmazásoknál fordul elő: 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 - többek között - felhasználhatja arra, hogy a hozzáférési ellenőrzést kikerülje, például avval, hogy a böngésző által kapott weblap nem az eredeti forrásból származik (de megjelenésében azonos lehet az eredetivel). Manapság ezt a támadásfajtát az ún. phishing támadás végrehajtásánál alkalmazzák. A Cross Site Scripting-et 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.

Tartalomjegyzék


1. Bevezetés

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. 

1. 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.

2. 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.

3. 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.)

1. típusú támadás

  • Mallory Aliznak egy rosszindulattal megszerkesztett URL-t küld (elektronikus levél vagy más formában) Alíznak.
  • Alíz rákattint a linkre.
  • A rossz weblapon lévő JavaScript Alíz számítógépén egy sebezhető HTML lapot hoz létre.
  • 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.
  • Mallory rosszindulatú scriptje Alíz jogosultságával futtathat paracsokat.

2. típusú támadás 

  • 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.
  • Mallory észreveszi, hogy Bob websiteja nem-állandó XSS sebezhetőségtől szenved (2. típus).
  • 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).
  • 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.
  • 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.

3. típusú támadás 

  • 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.
  • Mallory észreveszi, hogy a Bob website-ja 3. típusú XSS-sel sebezhető.
  • Mallory küld egy provokatív üzenetet, ami a többieket arra készteti, hogy megnézzék.
  • 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.
  • Később Mallory más felhasználó nevében bejelentkezik a site-ra, üzeneteket postáz stb.

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.

5. Az életből vett példák

Szó szerint százával találhatók példák XSS sebezhetőségre. Csak néhány, magyar website-ot sorolunk fel különböző típusú biztonsági lyukak illusztrálására. A tesztek 2008. május 19-én és 20-án futottak.  

6. XSS sebezhetőség elkerülése

Az XSS sebezhetőség elkerülésének első feltétele az, hogy minden speciális HTML karaktert kódoljanak. Általában ezt meg is teszik a különféle web-alkalmazások (kliens-oldali script). Nagyon sok programozási nyelvben van a kódolásra szolgáló  beépített függvény vagy könyvtár (quoting vagy escaping néven). 

Például a Python interpreterben:

~> python
Python 2.3.5 (#2, Aug 30 2005, 15:50:26) 
Type "help", "copyright", "credits" or "license" for more information.
>>> import cgi

>>> print "<script>alert('xss');</script>"
<script>alert('xss');</script>

>>> print cgi.escape("<script>alert('xss');</script>");
&lt;script&gt;alert('xss');&lt;/script&gt;

Itt az első print parancs egy kliens-oldali scriptet mutat, a második print pedig ugyanazt kódolva. A kódolt verzió egy böngészőben literálként fog megjelenni, és nem használható a HTML tag-ek speciális jelentése. Evvel meg lehet előzni azt, hogy a HTML lapra egy scpeciális scriptet szúrjanak be.

Még egy dolgora kell vigyázni, bár ez a helyzettől és az igényektől is függ. Tegyük fel, hogy egy képet szúrunk be ilyen formában:

 <img src='$url'>

Ha a képet a böngésző nem találja, akkor a támadó "nemlezeto.jpg 'onerror='alert(document.cookie)" kóddal egy eljárást indít el.

7. Hasonló sebezhetőségek


8. Hasznos linkek

 Általános információk

Támadási vektorok

Megelőzés

Előrodulások

Egyéb

 

 

Forrás: http://www.xssed.com/xssinfo