XSS kicsiknek és nagyoknak

xssÚj technikák megoldanak régi problémákat és hoznak újakat. A web 2 is megold egy több mint 10 éve húzódó problémát és webalkalmazásainkat átlépteti egy következő szintre, de ha nem kellő óvatosággal használjuk, akkor új támadási felületet szolgáltathatunk rosszindulatú látogatóknak.

Mi az XSS?

Az XSS olyan támadási technika amellyel egy weboldal veszélyes kódot jelenít meg, amit a browser lefuttat. A támadás a kliens ellen irányul nem a szerver ellen, és maga a weblap ami hordozza az xss támadásra alkalmas kódot a támadásnak nem a célpontja, hanem annak eszköze. Akkor miért is kell ezzel foglalkoznunk? Azért mert ha alkalmazásunk xss szempontból sebezhető, akkor ki fogják ezt használni ami semmi esetre sem kedvező.

Hogyan kerül a weblapra a veszélyes kód?

A veszélyes kód odakerülhet úgy, hogy maga a weblap készítője szánt szándékkal kiteszi. Bejuthat egy nem biztosított formon keresztül, a weblap publikus részébe való rögzítéssel, illetve egy olyan linkre kattintással ami kivált egy xss támadást.

Mit lehet XSS-sel véghezvinni?

Xss-sel loptak már hitelkártya adatokat, sessiont, felhasználói jelszavakat, tettek működésképtelenné vagy elérhetetlenné teljes oldalakat.
A leghíresebb és legnagyobb XSS támadást egy egyetemista fiú indította útjára. Eredeti célja az volt, hogy a barátnője MySapce oldalába belehekkelje magát vagyis, hogy megjelenítse az oldalán, hogy “Samy az én hősöm”. Aztán kis gondolkodás után rájött, hogy ha kicsit módosítja a scriptjét akkor nem csak a barátnőjénél fog a kedves kis felirat megjelenni, hanem minden MySpace usernál aki megnézi az ő adatlapját. Elindította a férget és úgy kalkulált, hogy 1 hónap alatt 2 embert fertőz majd meg, 2 hónap alatt 4-et és így tovább exponenciálisan növekedve. Kissé elszámította magát, mert 8 óra alatt 200 felhasználóhoz jutott el a féreg, 12 óra alatt 9.000-hez míg 18 óra múltán a fertőzött userek száma túllépte az 1 milliót, ami végül a MySpace szervereit kegyetlenül túlterhelte és két vállra fektette. Amikor Samy rájött, hogy ő okozta a leállást írt egy levelet a MySpace-nek, hogy bocs, véletlen volt és így lehet kijavítani. Persze a Myspace épp el volt foglalva a probléma javításán samy levelével nem foglalkoztak és elég sokáig tartott nekik talpraállítani a szolgáltatást. Egy szerver leállással elég nagy anyagi kárt lehet okozni, de gondolom ezt senkinek sem kell magyarázgatni. Samy összes elérhetősége kint volt az adatlapján, de ennek ellenére eltartott egy ideig míg az FBI valahogy megtalálta és falhoz állította.

Hogyan néz ki egy XSS támadás?

Az XSS támadásoknak nagyon sokféle megjelenése lehet, de lényegében mindegyik valamiféle scriptet próbál bejuttatni az oldalunkba. Tegyük fel, hogy van egy kereséshez használt input mezőnk az oldalunkon. Általában a találatokat megjelenítő oldal kiírja a kifejezést amire kerestünk. A wordpress például annyit csinál, hogy a találati oldalon a kereső inputba automatikusan beleírja a megadott keresési kifejezést. Ha megnézzük az oldal forrását azután, hogy rákerestünk a goranga szóra akkor ezt fogjuk találni:

<input type="text" id="s" name="s" value="goranga"/>

Namármost, ha a keresési mezőbe az alábbi kódot írjuk be akkor érdekes dolgokra juthatunk.

"><script type="text/javascript">alert('xss');</script>

Az első két karakter "> arról gondoskodik, hogy az input elemünk le legyen zárva, az ezt követő rész pedig egy egyszerű script ami ha lefut akkor már találtunk is egy XSS támadási pontot.
Szerencsére a wordpress szűri a bejövő adatokat és konvertálja a veszélyes karaktereket azok html entitásává, de más rendszerekben benne maradhatnak ehhez hasonló XSS lyukak.

Persze nem csak a keresési mezők, hanem mindenféle input mező, url változó megtámadható így ami később a html oldalon megjelenítésre kerül. Persze egy alert ablak habár bosszantó ugyan, de még nem fenyeget különösebb veszéllyel, de ha jobba belegondolunk, akkor éppenséggel bármilyen JavaScript kódot megadhatnánk itt. Például egy location.href-fel átirányíthatnánk a usert egy másik oldalra úgy, hogy a webhelyhez tartozó cookie-kat hozzáfűznék a meghívott url-hez. Ha mindenzt mondjuk egy olyan oldalon tesszük ahol be kell jelentkezni, akkor jó eséllyel már meg is vannak az áldozat bejelentkezési adatai. Ha történetesen a keresési kifejezés GET metódussal adódik át a szervernek és így megjelenik az url-ben is, akkor máris készíthetünk egy linket, ami tartalmazza az XSS támadásra szolgáló kódot, és ezt a linket már elküldhetjük bárkinek és már szépen gyűlnek is ármánykodó kezeink között a bizalmas adatok.

Hogyan védekezzünk az XSS ellen?

Minden usertől érkező adatot tisztogatni kell felhasználás előtt még a kliens oldalon. A fehérlistás szűrés a legideálisabb megoldás, azaz mivel tudjuk, hogy milyen bejövő adatot várunk a beérkezett adatot mondjuk egy reguláris kifejezés illesztéssel vizsgálunk. Persze ezután szerver oldalon is kell újra tisztogatni.

A böngészők alapvetően a same origin policy-val védekeznek (azonos származási forrás). Ez annyit tesz, hogy a a http://mashol.hu/index.html fileból meghívott http://valahol.hu/xss.js script nem fog hozzáférni a mashol.hu domain cookie információihoz. Ez sok esetben elég jó védelmet ad, de amint a fenti példából is láthatjuk nem hagyhatjuk ezt a biztonsági kockázatot egy az egyben a böngészőre, hanem nekünk magunknak is foglalkoznunk kell vele.

2 thoughts on “XSS kicsiknek és nagyoknak

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöljük.