XSS za velike in male

Splet je ranljiv. Spletne dveri, CMSji, forumi, Wikiji, spletni dnevniki in druge spletne aplikacije so vsak dan na udaru številnih napadalcev, ki imajo en sam cilj - pretentati uporabnika in pridobiti njegove zaupne podatke. Na svetovnem prizorišču se, kar zadeva varnost, dogajajo korenite spremembe. V kategoriji "najbolj zloglasni napadi" so prekoračitve medpomnilnika (buffer overflow) prepustile vodilno mesto napadom na spletne aplikacije. Med celotnim spektrom teh napadov pa so prestol brezkompromisno zasedli napadi XSS. Bodite pripravljeni. Njihov čas šele prihaja ...

Prekoračitve medpomnilnika (Monitor 11/06) so prevladovale približno 20 let. Razvijalci/programerji so jih v tem času dodobra spoznali in se pred njimi dokaj uspešno zaščitili. Tudi požarni zidovi, sistemi HIPS, randomizacija naslovnega prostora (ASLR) in druge metode danes že zelo otežujejo različne oblike prekoračitev (stack/heap/integer). A četudi niso več poglavitna tema računalniško-varnostnih novičarskih skupin, omenjene ranljivosti niso popolnoma izkoreninjene. Ne pozabimo, da je Microsoft aprila in maja po hitrem postopku in zunaj rednega mesečnega cikla zakrpal dve kritični prekoračitvi medpomnilnika (MS07-017 in 029).

Pri napadih na spletne aplikacije takih ovir (vsaj zaenkrat) ni. Teoretično s(m)o ranljivi vsi uporabniki medmrežja, neodvisno od vrste operacijskega sistema, arhitekture računalnika, privzetega brskalnika ali uporabljene spletne aplikacije. Strokovnjaki predvidevajo, da je približno 80 % vseh napadov usmerjenih na vrata HTTP, 95 % vseh uporabnikov pa uporablja brskalnik, ki podpira izvajanje kode JavaScript. Požarni zid nas pred spletnimi napadi ne more zaščititi. No, sicer lahko onemogočimo spletni promet ali blokiramo vrata TCP, na katerih deluje spletni strežnik, vendar se s tem "odžagamo" iz medmrežja, to pa, najverjetneje, ni bil naš namen. Zmogljivejši sistemi IDS (Intrusion Detection System) sicer omogočajo filtriranje zlonamerne mobilne kode na aplikacijski plasti, vendar so ti prijemi, glede na velikansko število znanih ubežnih vektorjev (escape vectors) zelo slaba uteha. Tudi sistemi IDS se, tako kakor protivirusni programi, spopadajo z znano težavo: odkrivanje zlonamerne kode na podlagi znanih vzorcev danes ni več učinkovito. Napadalčev habitat je tako skoraj brezmejen, primerna žrtev pa je lahko vsaka spletna stran in vsak uporabnik. Med celo paleto spletnih napadov, če imenujemo le nekatere, Remote File Inclusion (RFI), Cross-Site Request Forgery (CSRF), SQL injection, Directory traversal, Null-byte insertion, HTTP response splitting, Session fixation, Reverse Cross-Site Request (RCSR), JavaScript hijacking, URL redirection, XPath injection ..., pa je nesporni zmagovalec Cross-Site Scripting (XSS). Ta trivialna in minimalistična metoda pomete z vsemi.

V naši reviji smo o XSS sicer že pisali (Monitor 05/07). Vsekakor pa je problematika napadov Cross-Site Scripting dovolj pereča, da si zasluži podrobnejšo predstavitev.

Naj bo XSS ...

Izraz "križno izvajanje skriptov" (Cross-Site Scripting) se je v javnosti prvič pojavil leta 2000, skoval pa ga je Mark Slemko, eden izmed pionirjev pri odkrivanju XSS ranljivosti. Osebno priznava, da skovanka terminološko morda ni najprikladnejša: "Problem ni le v izvajanju skriptov in sploh ne nujno med različnimi spletnimi stranmi. Zakaj torej takšno poimenovanje? Ime se je prijelo v času, ko še niso bili znani vsi vidiki problema. In lahko mi verjamete, da smo imeli pomembnejše delo, kot je izbiranje imena."

Seveda je bilo križno izvajanje skriptov v "podzemlju" znano že nekoliko prej. Rober Hansen, "grey hat" heker, eminenca svetovne XSS scene in eden izmed najzaslužnejših (skupaj s Petko Petkovim, Jeremiah Grossmanom in Amit Kleinom) za to, da je napade XSS spoznala tudi širša javnost, priznava, da so bili ti napadi znani že sredi devetdesetih let prejšnjega stoletja. Guruji informatike so jih takrat imenovali preprosto "HTML injection". Tako Microsoft (www.microsoft.com/technet/archive/security/news/crssite.mspx) kakor CERT (www.cert.org/advisories/CA-2000-02.html) sta prvič javno spregovorila o tej problematiki leta 2000. Nekoliko bolj na tekočem je bilo (takrat) priljubljeno hekersko spletišče attrition.org, ki je evidentiralo enega izmed prvih večjih napadov XSS (attrition.org/security/advisory/misc/bwc.99-04-20.ebayla_bug).

Velik preskok v potencialu teh napadov je nedvomno povzročila uporaba javascripta (JS), ki se je ravno v tistem času (1996) uveljavljal kot jezik, primeren za dinamično oblikovanje spletnih strani. Javascript je v svojem bistvu precej omejen jezik. Razvijalci v Netscape Communications Corporation so se namreč zavedali nevarnosti, ki jo lahko povzroči nenadzorovano in avtomatizirano izvajanje mobilne kode. Javascript je t. i. "clent-side" jezik ali, drugače, izvaja se v uporabnikovem računalniku ali, natančneje, v brskalniku. Tak pristop pa je sinonim za težave. Čeprav ima JS vgrajene nekatere varnostne mehanizme, ti še zdaleč niso kos ustvarjalnosti in iznajdljivosti hekerjev. Najprej omenimo v brskalnik vgrajeni interpreter (tolmač), ki izvaja skripte v peskovniku (sandbox) in s tem izolira kodo od vitalnih delov sistema npr. datotečnega sistema, pomnilnika ... Skripta ima tako dostop zgolj do predmetov v oknu brskalnika, to pa ni nujno malo. Sploh če uporabljamo spletno bančništvo. Drugi varnostni koncept se imenuje "koncept enakega izvora" (same-origin policy). Ta naj bi onemogočil izvajanje skriptov, ki nimajo enakega izvora (domene, protokola in vrat). Oba varnostna modela sta seveda precej luknjasta.

Katere povezave so pri javascriptu dovoljene in katere ne

Kako tudi ne. Neverjetno je namreč, kam so razvijalci in hekerji pripeljali funkcionalnost javascripta. Seveda tudi za ceno premostitve vpeljanih varnostnih konceptov. Napadi na spletne aplikacije bi bili brez tega jezika veliko manj agresivni in raznoliki. Nekateri spletni napadi brez njega sploh niso izvedljivi. JS se, med drugim, uporablja pri preverjanju vrat in krajevnih omrežij, odkrivanju aplikacij v sistemih, napadih DNS-pinning, napadih Drive-by pharming, programih za beleženje tipk (keyloggers) in celo pri optimiziranju ranljivosti "heap overflow" v Oknih (Heap Spray, Heap Feng Shui). Šele z JS postane zlonamerna koda "pnevmatsko kladivo z dvojno protiročico, šeststopenjskim sistemskim menjalnikom in laserskim namerilnikom", kot se je slikovito izrazil eden izmed obiskovalcev priljubljenega slovenskega spletišča. Jezik, ki je pred desetletjem veljal za nepomemben in drugorazredni, je danes med vodilnimi, vsaj v določenih sferah.

Naj bo raznolik ...

Po podatki družbe "Webappect" (www.webappsec.org/projects/statistics/) je 85,57 % vseh spletnih strani ranljivih za XSS. Analizo so izvedli na vzorcu 31.373 naključnih strani, ranljivih je bilo 26.667. V Sloveniji ni stanje seveda nič kaj bolj rožnato Še več, slovenski spletni prostor je ranljiv z napade XSS po dolgem in počez. ISP, finančne ustanove, državne institucije, spletne trgovine, priznana podjetja, izobraževalne ustanove, medijske hiše, časopisne hiše ... vsi (no, skoraj) pokleknejo pred trivialnim napadom, ki ni daljši od elementa <script> in predmeta alert(). O konkretnih imenih je seveda brezpredmetno govoriti. Seznam bi bil namreč zelo obsežen. Recimo, da je ranljiva "skoraj vsaka" spletna stran, katere se spomnimo. Domača ali tuja. V spletu se najde celo stran (www.xssed.com) ki v slogu bolj znanega Zone-H (www.zone-h.org) zaznava vse odkrite (in prijavljene) napade XSS. Velika imena in korporacije ne manjkajo.

Odstotek spletnih strani, ki so ranljive za določene napade

Vzrok težav seveda leži v ranljivi aplikaciji v spletnem strežniku in interpretiranju vnosnih parametrov. Povedano nekoliko drugače: XSS dejansko ni napad na spletno aplikacijo, temveč na uporabnike, ki ranljivo aplikacijo uporabljajo. Strežnik/aplikacija pa igrata pomembno vlogo aktivnega posrednika.

Vzemimo primer hipotetičnega spletnega iskalnika, v katerega smo vnesli iskani niz "Revija Monitor". Parameter URL bi v navedenem primeru lahko bil takle: http://URL/najdi.php?string=%22Revija+Monitor%22. Rezultat bi bil seveda izpis vseh zadetkov z omenjenim iskalnim nizom. Problem nastane, ko spletna aplikacija interpretira in posreduje tudi značke HTML (tags), vstavljene poleg samega iskalnega niza. Čeprav se v napadu XSS lahko dejansko uporabi veliko značk, je ena med njimi še posebej priljubljena: <script>. Ta namreč omogoča izvajanje javascriptne kode. Parameter URL bi torej lahko modificirali takole: http://URL/najdi.php?string=<script>alert("Revija+Monitor");</script>. Vrnjeni rezultat bo seveda popolnoma drugačen od pričakovanega. Na uporabnikovem zaslonu se bo namreč prikazalo opozorilno okno.

Rezultat "iskalnega" niza http://URL/najdi.php?string=<script>alert("Revija+Monitor");</script>

Majhno, nepomembno in nedolžno opozorilno okno, ob katerem večina uporabnikov zgolj zamahne z roko. Težava, ki se je večina ne zaveda, je v tem, da je prikazno okno posledica namensko izvedene kode na strani uporabnika na način, ki ga razvijalci aplikacije niso predvideli. Izvajanje arbitrarne kode pa je že po definiciji vrzel v varnosti. Kakor bomo kmalu odkrili, se strup skriva v majhnih stekleničkah.

Poznamo tri različne oblike križnega izvajanja skriptov: DOM-based ali krajevni XSS (tip 0); non-persistent/reflected ali odsevni XSS (tip 1); persistent/stored ali trajni XSS (tip 2).

Za preizkušanje vrzeli XSS lahko uporabimo naslednje spletne strani, ki so namenjene preizkušanju spletnih skenerjev. Križno izvajanje skriptov je tu popolnoma legalno:

demo.testfire.net

testaspnet.acunetix.com

zero.webappsecurity.com

DOM-based XSS

DOM (Document Object Model) je vmesnik brskalnika, ki opisuje predmetno zgradbo spletne strani in omogoča dinamično urejanje posameznih elementov. Posebnost pri DOM-based XSS je, da se celotni napad izvede krajevno v brskalniku. Napadalec dejansko ne potrebuje spletnega strežnika z ranljivo aplikacijo. Zelo znan DOM-based XSS je bil pred časom odkrit v vtičniku PDF (www.wisec.it/vulns.php?page=9). Zloraba je (bila) zelo preprosta: http://URL/datoteka.pdf#string=javascript:alert("XSS"). Pomembno vlogo ima znak "#", ki se pogosto pojavlja v DOM-based XSS izvedbah. Čeprav napad poteka prek spletnega strežnika, ima ta zgolj vlogo pasivnega posrednika. Strežnik dejansko ignorira vse parametre URL za znakom "#". Preostanek niza tako interpretira zgolj ranljiva aplikacija, v konkretnem primeru vtičnik Adobe Reader, na uporabnikovi strani. Poglejmo še nekoliko bolj zabaven prikaz funkcionalnosti vmesnika DOM. Odjadrajmo na spletno stran korporacije Microsoft (no, da se izognemo nesporazumom: spletna stran je lahko poljubna) in v naslovno polje vnesimo naslednje:

javascript:document.write('%20%20<b>0wn3d%20by%20DOM</b>');alert(document.domain);

Naredimo zaslonsko sliko in jo razpošljimo znancem. Nedvomno bodo impresionirani ;)

Hekerji vdrli v Microsoft? Ne, le prikaz funkcionalnosti DOM

Odsevni (reflected) XSS

... je daleč najbolj razširjena in uporabljena oblika križnega izvajanja skriptov. Zgornji primer hipotetičnega spletnega iskalnika, pri katerem smo iskalni niz preuredili s <script> značko, je idealni prikaz odsevne metode XSS. Taki napadi največkrat pridejo v obliki spletne povezave (t. i. GET Request XSS), le-ta je seveda ustrezno "maskirana" in tako deluje manj sumljivo. Napadalci pogosto uporabljajo znane prijeme: URL escaped encoding, UTF-7 encoding, UTF-8 encoding ..., pri katerih zlonamerni niz preprosto prepišejo z ustrezno kodno tabelo. Omenjeni načini URL prikrivanja so sicer bolj znani pod nazivom URL obfuscation. Naš poskusni iskalni niz bi bil torej lahko videti takole:

http://URL/najdi.php?string%3D%3Cscript%3Ealert%28%22Revija+Monitor%22%29%3B%3C/script%3E

ali takole:

http://URL/najdi.php?string+AD0APA-script+AD4-alert(+ACI-Revija Monitor+ACI-)+ADsAPA-/script+AD4-

Poleg tega da je spletni naslov zdaj videti precej manj sumljiv, se napadalec s takimi prijemi uspešno izogne tudi marsikateremu filtru, ki preverja vnosne parametre.

Nekoliko redkejši so t. i. napadi POST Request XSS. POST in GET sta HTTP zahtevka, s katerima odjemalec od strežnika zahteva (Request) določeno vsebino. Spletni strežnik na vsako zahtevo POST ali GET odgovori z odzivom (Response). Bistvena razlika med GET in POST križnim izvajanjem skriptov je, da slednjih ne moremo formulirati v obliki spletne povezave. Najosnovnejši XSS "vektor" je tako onemogočen. Napadalci se takih primerov lotevajo z uporabo spletnih obrazcev (forms), v katerih kakor metodo zahtevka navedejo POST. Pri iskanju je nujna uporaba različnih HTTP proxy programov (npr. Paros, Burp ...), s katerimi lahko prestrezamo zahtevke HTTP in tako pridobimo parameter URL, ki ga nato uporabimo v obrazcu. Kako najlaže odkrijemo, ali imamo opravka s POST ali GET različico? Pri POST metodi URL parametri niso vidni v naslovnem polju brskalnika.

Princip delovanja odsevnega XSS je v obeh primerih enak. Uporabnik s klikom povezave (GET) ali spletnega gumbka (POST) pošlje strežniku ustrezno malformiran zahtevek, strežnik zahtevek interpretira in posreduje uporabniku, kjer se izvede zlonamerna koda.

Tako deluje odsevni napad XSS.

Trajni (persistent) XSS

Če odsevni XSS velja za najbolj razširjenega, za trajni XSS velja, da je najnevarnejši. Od odsevnega križnega izvajanja skriptov se razlikuje zgolj v eni, vendar ključni podrobnosti: stalno je lociran v spletnem strežniku. Napadalec mora zlonamerni niz zgolj enkrat "dostaviti" spletni aplikaciji, ki ga nato shrani v zbirko podatkov. Ko uporabnik naslednjič obišče ranljivo spletno stran, se XSS avtomatično izvede. Za razliko od odsevnega XSS, kjer mora uporabnik dejansko klikniti povezavo. Trajni XSS se pogosto uporablja v napadih na spletne aplikacije Web 2.0.

Tako deluje trajni napad XSS.

XSS vse naokrog ...

Ročno modificiranje parametrov URL je eden izmed bolj zapletenih načinov odkrivanja ranljivosti, povezanih s križnim izvajanjem skriptov. Seveda lahko uporabimo tudi avtomatizirana orodja, ki nam zelo poenostavijo delo. Med komercialnimi so omembe vredni najmanj trije izdelki: Acunetix Web Vulnerability Scanner, Watchfire AppScan ter SPI Dynamics WebInspect. Navedeni programi so nedvomno prvaki v svoji kategoriji, saj omogočajo iskanje vrzeli XSS z različnimi ubežnimi vektorji (escape vectors) in metodami izmikanja (filter evasion), ki jih z namenom pretentati različne filtrirne mehanizme, katere lahko uporablja spletna aplikacija, uporabljajo tudi hekerji. Seveda našteta orodja uspešno odkrivajo tudi druge znane oblike vrzeli v spletnih aplikacijah. Med brezplačnimi velja omeniti ScreamingCSS. Omenjeni perlovski program je sicer zelo arhaičen in omogoča zgolj iskanje najosnovnejših vektorjev XSS. ScreamingCSS je namreč eden izmed prvih avtomatiziranih programov za odkrivanje takih ranljivosti. To se kaže tudi v samem imenu programa (CSS in ne XSS). V začetku so izvedenci križno izvajanje skriptov označevali preprosto s CSS. Da bi se izognili popolni zmedi, kratica je bila seveda že v uporabi za Cascading Style Sheets ter Content Scrambling System, se je uveljavila označba XSS.

AppScan, eden izmed najboljših programov za odkrivanje ranljivosti XSS.

Za odkrivanje vrzeli XSS pa je na voljo še en, zelo preprost, a nadvse učinkovit način. V vse spletne obrazce in polja, ki uporabnikom omogočajo interakcijo s spletno aplikacijo, vstavljamo poljubni vektor XSS. Za začetek lahko uporabimo že znani niz <script>alert("Revija+Monitor");</script>. Nad rezultati znamo biti (ne)prijetno presenečeni. Trenutno je javno znanih več kot sto različnih vektorjev XSS (www.gnucitizen.org/xssdb/). Zelo malo strani se lahko pohvali, da so imune na vse med njimi ...

Omenjeni postopek nam lahko zelo olajša in pospeši tudi brskalnik Firefox, ki ga krasi cela paleta nadvse uporabnih vtičnikov. Za naše potrebe zadostuje vtičnik Greasemonkey (addons.mozilla.org/en-US/firefox/addon/748/) in skript XSS Assistant (www.whiteacid.org/greasemonkey). Največja prednost asistenta za križno izvajanje skriptov je, da omogoča vstavljanje vektorjev XSS v skrita polja.

XSS Assistant omogoča vstavljanje vektorjev XSS v skrita polja.

Naj bo nevaren ...

Tako, odkrili smo XSS ranljivo spletno aplikacijo. Kaj zdaj? Napadalec lahko uporabi XSS za izvajanje štirih različnih oblik napadov: ribarjenje (phishing); krajo piškotkov (cookie stealing) in posledično ugrabitev seje (session hijacking) ali identitete; zavrnitev storitve (DoS; Denial of Service) ter XSS razobličenje (XSS defacement).

Pri ribarjenju napadalec formulira ustrezen URL, ki vsebuje javascriptni predmet "document.location" in tako preusmeri nič hudega slutečega uporabnika na ponarejeno, vendar enako spletno stran. V ozadju se seveda izvaja skript, ki zaznava vse uporabnikove vnose. Programi za beleženje tipk (keyloggers), napisani v javascriptu, niso nobena redkost.

Piškotki so besedilne datoteke, shranjene v uporabnikovem računalniku, v katerih spletne strani hranijo določene informacije o uporabniku. Pogosto se uporabljajo tudi kot identifikatorji seje. Pri kraji piškotkov napadalec uporabi predmet JavaScript "document.cookie", s katerim pridobi podatke, shranjene v piškotku, in tako lahko prevzame identiteto uporabnika na strani, ki je piškotek izdala. Enega izmed načinov ugrabljanja seje, imenovanega "utrjevanje seje" (Session fixation), je predstavil tudi slovenski računalniško-varnostni raziskovalec Mitja Kolšek (www.acros.si/papers/session_fixation.pdf).

Pred ugrabitvijo seje se lahko zavarujemo z uporabo piškotkov HttpOnly. Omenjeni piškotki so nastali v Microsoftovi kuhinji, podpirajo pa jih IE, Opera, Safari in Konqueror. Firefox2 jih privzeto ne podpira, vendar lahko težavo premostimo z uporabo vtičnika HttpOnly (addons.mozilla.org/en-US/firefox/addon/3629). Ognjena Lisica bo piškotke HttpOnly podpirala v prihajajoči tretji različici. Ti piškotki strukturi DOM onemogočajo dostop do vsebine piškotka. Uporaba predmeta "document.cookie" je tako brezpredmetna. Seveda pa mora atribut HttpOnly uveljavljati spletna aplikacija (več informacij: msdn2.microsoft.com/en-us/library/ms533046.aspx).

Zavrnitev storitve (DoS) se izvede s preusmerjanjem uporabnika na lokacijo, kjer je zlonamerna javascriptna koda, npr. takole: <script src="http://URL/dos.js"></script>. Koda, ki povzroči DoS, dejansko ni daljša od nekaj vrstic. Preprosta neskončna zanka (infinite loop) ali pomnilniška luknja (memory hog) popolnoma zadostuje. Na srečo brskalniki nekatere najočitnejše tovrstne "deformacije" kode odkrijejo in ponudijo možnost prekinitve izvajanja skripta.

S t. i. XSS razobličenjem pa lahko napadalec spremeni prikaz vsebine spletne strani v uporabnikovem brskalniku. Za razliko od klasičnih razobličenj, pri katerih vsiljivec dejansko modificira vstopno stran (po predhodnem vdoru v strežnik), pa v primeru XSS razobličenj ostanejo podatki v spletnem strežniku nedotaknjeni. Vdor se seveda ne zgodi. Spremembo prikazovanja strani povzroči podtaknjena javascriptna koda, vrzel XSS in spletna povezava, ki jo je uporabnik kliknil. Spretno izvedena XSS razobličenja se pogosto uporabljajo za manipulacijo z informacijami v obliki vstavljanja neavtoriziranih novic na spletne dveri medijskih družb in časopisnih hiš.

Prikaz XSS razobličenja in prikaza lažnih novic. Zaslonska slika se je pred časom pojavila na znanem slovenskem forumu. Naj znova opozorimo, da so vsi podatki v strežniku ostali nedotaknjeni. Skrbniki strani so vrzel že odpravili.

Verjetno ni treba posebej poudariti, da je od XSS razobličenja do ribarjenja zelo majhen korak. Poleg tega imajo omenjeni napadi še eno zelo slabo lastnost: precej lahko omajejo kredibilnost ustanove.

Kje je vzrok za tako učinkovitosti XSS? Križno izvajanje skriptov ne izbira žrtev. Kakor smo že omenili: operacijski sistem, arhitektura, brskalnik ali spletna aplikacija ne igrajo nobene omembe vredne vloge pri sami zaščiti. Nepomemben je celo sam jezik, v katerem je napisana spletna aplikacija: PHP, perl, ASP, JSP, CFM, ruby, python ..., vsi so enako dovzetni za napade XSS. Druga težava je sam javascript. Danes ga podpira skoraj vsaka malce naprednejša napravica. Mobilni telefoni, ročni računalniki, iPodi, omrežna oprema ... Vse te naprave so, zahvaljujoč javascriptu, ranljive za XSS. Seveda XSS ni omejen zgolj na uporabo javascripta. Napade je prav lahko izvesti tudi z Microsoft VBScript ali Macromedia ActiveScript. JavaScript je najbolj priljubljen zgolj zaradi svoje razširjenosti in podprtosti. Mirno lahko zatrdimo, da je križno izvajanje skriptov univerzalna ranljivost.

Kako se lahko zaščitimo?

Zaščite pred XSS se lahko lotimo na dveh ravneh: aplikacijski in uporabniški. Na aplikacijski ravni lahko uporabimo različne prijeme:

Na uporabniški ravni se lahko uspešno zavarujemo le na en način: onemogočimo izvajanje JavaScript/Active Scripting/Java aApplets, izključimo vse vtičnike, avtomatično metaosveževanje in prikazovanje slik. Seveda se nihče med nami ne bi strinjal s tako korenitimi ukrepi (to bi namreč bilo enakovredno uporabi besedilnega brskalnika Lynx :-), torej je nujno treba skleniti kompromis med uporabnostjo in varnostjo. Velik korak k boljši zaščiti lahko naredimo že z omejevanjem javascripta. Uporabljajmo ga izključno na staneh, ki jim zaupamo. Lahko si omislimo tudi vtičnik NoScript (addons.mozilla.org/en-US/firefox/addon/722), ki nam vse skupaj precej olajša in celo odkriva nekatere oblike vektorjev XSS. Če smo po naravi nekoliko avanturisti, lahko preizkusimo tudi vtičnik XSS Warning, ki nadvse zanesljivo odkriva odsevne napade XSS. Vtičnik še nima uradnega soglasja s strani Mozilla Corporation, zato je pred namestitvijo potreben premislek. Na naših preizkusih se je obnesel odlično.

Vtičnik NoScript za Firefox

Vtičnik XSS Warning za Firefox

Kam naprej?

Dokončne rešitve pred napadi XSS seveda ni. Dokler bodo spletne aplikacije dopuščale interakcijo z uporabniki (ali sploh lahko gre drugače?), bo tudi možnost napadov XSS. V taki ali drugačni obliki. Iznajdljivosti in sposobnosti hekerjev vsekakor ne gre podcenjevati.

Naslednji korak v razvoju napadov XSS je nedvomno avtomatizacija pri iskanju in zlorabi vrzeli Cross-Site Scripting. Prvi koraki v tej smeri so bili že uspešno izvedeni. Ledino je oral črv "Samy is my hero". Eden izmed uporabnikov dveri MySpace si je želel biti zelo priljubljen (v smislu, da bi njegov vzdevek čim več uporabnikov vstavilo na svoj seznam prijateljev); cilj je bil 1000 uporabnikov. Ob pomoči vrzeli XSS je črv v 24 urah "okužil" približno milijon uporabnikov tega priljubljenega spletišča. Samy je nedvomno postal zelo priljubljen. Nato so skrbniki dveri zaprli in odpravili vrzel.

Naslednjo stopnjo predstavlja skener Jikto, ki ga je Billy Hoffman predstavil na hekerski konferenci ShmooCon. Jikto je v svojem bistvu skener, napisan v javascriptu, ki omogoča odkrivanje XSS/SQL injection pomanjkljivosti na spletnih straneh. Vendar pa naj bi Jikto dopuščal še veliko več. Okužene računalnike lahko povezuje v omrežja botnet in prek njih izvaja napade DDoS, v slogu spletnih pajkov prečesava splet in odkriva/kompromitira ranljive spletne strani ... Čeprav je koda po mnenju izvedencev zelo hroščata, vseeno dopušča veliko manevrskega prostora za optimizacijo. Metode, ki jih uporablja Jikto, niso nove, vendar so prvič združene v kompleksno orodje, ki ga bodo najbolj veseli skriptni otročaji.

Vsekakor bo držalo naslednje: XSS je novodobna prekoračitev pomnilnika, javascript pa lupinska koda. In ko smo že prepričani, da smo se ustrezno zavarovali pred napadi XSS, je pred vrati že nova grožnja - CSRF (Cross-Site Request Forgery). Začarani krog se tako vrti naprej. Vendar pa je to že druga zgodba.