A ZDNet rovatvezetője mindig érdekes hálózatvédelmi trükköket elemez a ZDNet Anchordesk virtuális lapjain. Most éppen az XSS veszélyt és annak elhárítást elemezte. A webkorszak hajnalán a hálószemeken sima szövegállományok voltak, statikus tartalommal. Közben kialakultak a dinamikus lapkészítési technológiák, amelyek már nem csak buta szövegeket hoznak a gépeinkbe, hanem programtulajdonságokkal felruházott objektumokat, amelyek a nézőt elkápráztató hatásaik mellett elképesztőkkel is bőven bírhatnak. A gyanútlan alkalmazó észre sem veszi, hogy a háttérben egy sereg információt kiganajoznak a gépéből, amelyek nagy része minimum a személyiségi jogait sérti, ha nem éppen agresszív támadás, vagy azt megelőző akció.
Az XSS támadási trükk
Az egyik ilyen aknamező az, ahogy a Cross-Site Scripting (XSS) gépeken átnyúló interpretatív végrehajtási (kereszt-forgatókönyv) technológia használata, amelyet egyre népszerűebben használnak a gyanútlan szörfözők személyes adatainak a felderítésére.
A közismert buffer overflow, puffertúlterhelési technológia arra is alkalmas, hogy a gyanútlan ügyfél gépén teljesen át tudja venni a vezérlést egy rosszindulatú hálószem gazdája. Az XSS esetében ugyan erről szó sincs, de a keletkező kár mégis jóval nagyobb lehet. Lényegében indirekt módszer az érzékeny adatok megszerzésére, amely akár a meglopott alkalmazó másodlagos támadhatóságához vezethet. A trükk révén a támadó ellophatja vagy eltérítheti a levelek adatait, manipulálhatja a hardver és a szoftver beállításait, sütik (cookies) adatait lophatja el, de akár bankszámla- vagy bankkártya-információkat, személyi és adószámot stb. is.
A sütik elvileg veszélytelenek, legalábbis, ahogy az IETF szabványkészítői azokat eredetileg megálmodták. Például, az Amazon felismer engem, ha feléjük járok, és ettől a dinamikus weblapon megjeleníti a speciálisan engem érdeklő újdonságokat. Még a nevem is kiírja, udvariasan. Amikor egy szörföző életében először tapasztal ilyet, meglepetésében tán még le is petézik. De, mivel benne a távoli hely a belépő adatainkat tárolhatja, egy rosszindulatú behatoló az eltulajdonításával hozzájuthat az amazonos belépési információinkhoz. Ezek ellen a jobb e-boltok már pótvédelmekkel is védekeznek, de a gyengébb védettségű helyek támadása a sütiinformáció birtokában gyakorlatilag gyerekjáték. Így rendelhetnek a nevünkben könyveket, és fizetnek a már ismert bankkártyánkkal. Nem rossz trükk!
A sütik belső tartalma, szerencsére, az ahány ház, annyi szokás stílusúak, ezért nem kapásból tudja meg az adatainkat egy behatoló, hiába másolja le. Ha nem ismeri a szerkezetét, akkor nem sokra megy vele. Nos, a crackereket nem kell félteni ettől. Amire rá lehet jönni, arra rá is fognak. Ezzel együtt, ha az ember szörföl a neten, és formokat tölt ki rendre, tapasztalhatja, hogy a mezőkben a jobb böngészők esetén a kitölthető adatvariációk rögtön megjelennek, jelezve, hogy a neten terjedő típusmegoldást használták a programozásakor, aminek az objektum osztályai már közismertek. Így sajnos elég hamar rá lehet jönni egy süti szerkezeti részeinek a funkcióira. A probléma ellen csak a kriptikus sütik alkalmazása véd. Egy jó e-bolt e nélkül például kész életveszély!
Hogy a gyanút az XSS támadó elkerülje, az adatainkat nem közvetlenül küldi saját magához, hanem olyan köztes helyre, amihez viszont van hozzáférése. Rendszerint villanypostán küldött levelekben helyezik el ezekre a tranzit hálószemekre utaló, egyébként szándékosan hibás linkeket. A http:// kezdetűekről például ki gondolná, hogy hibás címre mutatnak. De egy hibás URL kódolható HEX alakban is, mint például: 0x0068, 0x0074, 0x0070, 0x003A, 0x002E, 0x002F. Egyébként pedig úgy néz ki az URL, mint egy keresőrendszeri cím. Lehet azonban a weblapon elhelyezett titkosított szövegben található, ezért láthatatlan link is a trükk hátterében.
Már ócska trükknek tűnik, de még ma is szedi áldozatait az a trükk, amikor jön egy kérdezőablak, hogy adjuk meg újra a belépési információinkat, és akkor lopnak. Közben a támadó akár át is vezérelheti a gyanútlan alkalmazót a saját weblapjára, amelyről viszont a böngésző úgy hiszi, hogy megbízható (!). A sütiinfó alapján ugyanis ezt már nem veheti észre, mert az egyezhet. Ezek után a megbízhatónak nyilvánított hálószemről a behatoló akármit megtehet, akár katasztrofális támadást is indíthat a megtámadott gép ellen. Ez ma a tipikus vírusírói stílus legfőbb jellemzője.
XSS-támadás elleni védelem
Mit lehet tenni a támadások korlátozására vagy ellehetetlenítésére? Azon túl, hogy kikapcsolhatjuk a scriptek végrehajtását. Nem jó ötlet. Ma a hálón szinte már semmit nem láthatunk ilyen üzemmódban. Ha MS IE-ra vagyunk átkozva, mint a világhálón a döntő többség, a biztonsági szintet emelhetjük HIGH, azaz, a legmagasabb szintre. És óvatosabban bánunk az egerentyűnkkel, nem kapkodjuk el, milyen URL linkekre kattintgatunk rá. Na, ezt se könnyű betartani.
A működő megoldás csak a szerveroldalon hozható létre és automatizálható. Mind a lapok, mind az alkalmazások programozásánál oda kell figyelni erre a problémára. A jó hír, hogy míg korábban komoly e-boltokban sem figyeltek erre a problémára, ma már sokkal jobb a helyzet. A hálón terjedő e-bolt megoldások egyre több olyan védelmet tartalmaznak, amelyek kiküszöbölik az XSS egyébként nélkülözhetetlen használatából eredő problémákat is.
Azért Vámosi Róbert mégiscsak azt tanácsolja: gondoljuk meg, hová klikkelünk, és mikor vagy kinek adjuk meg az adatainkat, különösen a jelszavunkat. Nem nyerő az automatikusan letárolt jelszókezelés sem, ha mondjuk a pénzügyeinkről van szó (ezt meg én mondom, a cikkíró, mint több e-banki szolgáltatás élenjáró alkalmazója - eddig csont nélkül).
A ZDNeten érdemes rákeresni Vamosi nevére, mert hasonló ötletekből egy csomót találhatunk a rovatában.