I01 – Uso de secuencias de comandos en sitios cruzados (XSS)

I01 – Gure webguneetan script sekuentzien erabilera (XSS)

2025(e)ko urtarrilaren 13(a) Celia Catalán

Orokorrean deitzen zaio bere ingeles nomenklatura, Cross-Site Scripting, mota hau aplikazioetan dauden ahultasunak askotan gutxietsiak izaten dira enpresen garapen-taldeak, tradizionalki lotu direlako nabigatzailearen bidezko eraso puruak bezeroari eragiten diotenak, haratago joan gabe 'zenbait estekak phishing saiakera gisa, etab. Baina errealitatea da mota hau' erasoen, bereziki besteen ustiapenarekin konbinatuta egon daitezkeen ahultasunak, kalte garrantzitsua eragin dezakete.

Nagusiki honen barruan daude kode gaiztoaren injezioa (oro har JavaScript, baina baita vbscript ere) kasuan konkretuetan), beste batzuek sortutako aplikazioen edo webguneen edukian "erabiltzaileek ikusi dezakete. Kode hau erabiliz, datuak lapurtu daitezke." sentsibleak, hala nola cookieak edo kredentzialak, erabiltzailea guneetara birbideratzea maliziosoak, edo erabiltzailearen identitatea ordezkatzeko, egiteko zure izenean baimenik gabe egindako ekintzak.

XSS mota desberdinak daude, funtsean hiru handien sailkapen nagusiak azpimarratuz, zeinak xehetasunez azalduko diren jarraipena.

Horretarako, eta hasi aurretik, se "aplikazio bat erabiliko du, zeinaren ahultasun batzuk aktibatuta dauden (horretan" 'XSS-rekin lotutako kasuak), ikaskuntzarako. Aplikazioa' login formulario oinarrizko, non sartzen den, ondo erabiltzaile rolarekin edo administrazioa panel batera, non kudeatzen diren artikulu batzuk bere prezioa eta administratzailea izanez gero, erabiltzaileen kudeaketa aplikazioa, baita beste alderdi batzuk.

Motak

XSS islatua

Orokorrean, erabiltzailearen sarrera prozesatzen denean eta zuzenean web orrian islatzen denean gertatzen da, behar bezala balioztatu edo kodetu gabe. Honek kodearen injezioa ahalbidetuko luke, hala nola, eskaera hori exekutatzen denean, injezio horren emaitza islatuko dela. Horrela, URL bat bidali daiteke (agian web helbide laburtzaile baten azpian ezkutatuta, erasotzailearen biktimari bidalitako). Horrela, erabiltzaileak esteka hori exekutatzean, URLan dagoen JavaScript kodea ere exekutatuko luke, erasotzailearen webgunean birbideratzea izan daitekeena, non, adibidez, erabiltzailearen saio cookiea lapurtuko litzatekeen orri aktualean. Beste adibide bat, biktimaren web nabigatzailean "hook" gaizto bat exekutatzea izango litzateke, erasotzaileak kontrolatuko lukeena orduan (Beef aplikazioaren bidez, web ustiapenerako ezaguna den framework bat, adibidez).

Horrela, aipatutako ahultasunarekin lotutako aplikaziora itzuliz, artikuluen zerrendako atalean, erabiltzaileari artikulu jakin batzuk bilatzeko aukera ematen dion bilaketa-eremua egiaztatzen bada:

'user1' gisa aplikazioan konektatuz, erabiltzaile horren artikuluetara sar daiteke, artikuluen zerrendan, "Kudeatu Zure Elementuak" menuaren bidez.

'Artikulu bat (izena edo deskribapena) bilatzen bada, adibidez "item 1":

Ikusi daitekeenez, emaitza erantzunean islatzen da.

Orain bilatzen saiatuko da 'nabigatzaileak kode gisa interpretatzen duen ikusteko script-sekuentzia bat' ez erantzuna:

- HTML kodea inyectatuz (adibidez, ohiko goiburua

...

tag-en artean):

Adierazten du, gutxienez, HTML kodea irakurtzen ari dela inolako iragazkirik gabe, HTML kodea inyectatzea uzten duela, nabigatzaileak interpretatzen duena.

- JavaScript kodea inyectatzen. Ez da lortuko ohiko mezuekin. , baina payload asko daude, PortSwigger Academy orrian erreferente ona izanda. Edo bestela, URL kodifikazio desberdinak probatuz. Adibidez, posible den payload bat irudi mota HTML objektu bat injetatzea litzateke, kargatzean errore batek script bat exekutatzea eragiten duena (eta hor, probatzeko, ohiko alert):

- 'BurpSuite-rekin eskaera interceptatuz, benetan Ajax bidez kargatuko den bilaketaren erantzuna aztertzen da search parametroaren bidez' items_search.php:

Erantzuna nabigatzaileari birbidaltzean, ahultasuna egiaztatu daiteke:

Hurrengo pausoa, adibidez, erasotzailearen makinako zerbitzu txiki bat altxatzea izango litzateke, payload-a apur bat aldatzeko (adibidez, ... erabiltzailearen cookiea lapurtzeko, kontsulta hori birbidaltzen duenak. Adibidez, URL-a bilaketa parametroan kodifikatuta eta web helbide laburtzaile batean sartutako payloadarekin webguneko administratzaileari bidaltzen bazaio.

XSS gordeta

Hau XSS moten artean kritikoenetako bat da, injezioa iraunkorra izan daitekeen kasu bakarra delako, izan ere, kode gaiztoa betiko gordetzen da zerbitzarian, eta eduki hori ikusten duten erabiltzaile guztiei eragiten die, ez bakarrik esteka gaiztoan klik egiten dutenei. Hau da, zerbitzariarekin interakzioa dago, eta horrela beste ahultasun batzuekin konbinatu daiteke, baita sarbidea kontrolatzeko ere. Hori iritzi iruzkin formularioei buruzko kasu tipikoa da webgune batean, etab. Hala ere, beste datu mota batzuetan ere eman daiteke, erabiltzaileak aurretik sartutako emaitzak gordetzen dituzten taulen moduan, non eremuak behar bezala balioztatu ez diren.

Aurreko adibideari itzultzen, aplikazio ahularen kudeaketan, artikulu berriak sortzeko botoi bat dagoela ikus daiteke (Add New Item). Artikulu berriaren edozein eremutan kodea injetatzea lortzen bada (bakoitzaren bidez, edo web proxy batekin eskaera atzitzen), espazioen eta beste karaktere berezien URL kodifikazioa kontuan hartuta), XSS hau aplikazioaren erabiltzaile guztientzat gordeko da.

Beste erabiltzaile batekin (user2) saioa hasi ondoren, orain XSS jakin bat txertatzea da helburua, orrialdeak puntu honetan ahultasun bat duela frogatzeko. Adibidez, aurreko adibidean bezala, artikulu berriak sortzea baimentzen da. Deskribapen eremuan motako payload bat txertatzen bada (nahikoa luze dena beharrezko karaktereak txertatzeko). Artikulua gorde ondoren:

"Behar denean ahulgarria dela egiaztatu ondoren, artikulua ezabatzen da (edo editatzen da, eta deskribapena ordezkatzen da) eta beste bat sortzen da, zeinak ez duen zuzenean emaitza pantailan erakusten, baizik eta, adibidez, erabiltzailearen cookiea erasotzailearen makinako web zerbitzari batera bidaltzen du, hurrengo payloadarekin:"

Aldaketa/alta exekutatzean, ez da ezer arraroa agerikoa izango emaitza-taulan:

Hala ere, erasotzailearen makinako web zerbitzarian:

Administratzaile erabiltzaileak, artikulu guztietara sarbidea duena, orri hori irekitzen duenean:

eta erasotzaileak exekutatuko duen script-a isilean abiarazten denean, administratzailearen cookie-a erasotzailearen web zerbitzariari egindako eskaeraren parametro gisa agertuko da:

"Islatutako XSS-rekin alderatuta, aldeak (eta kritikalitatea) nabarmenak dira: erregistro horretara sarbidea duen edozein erabiltzailek eragina izango du, islatutakoan, ordea, erasotutako erabiltzaile bakoitzari esteka gaiztoa bidaltzea eskatuko litzateke."

Era berean, script hau Beef-en hook.js batekin ordezkatu daiteke, erabiltzaileen nabigatzailea kontrolatzeko, orri honetara konektatzen direnean, edo beste informazio sofistikatuagoak exekutatzeko, web zerbitzariaren beste informazio bat arriskuan jar dezaketenak.

DOM oinarritutako XSS

DOM (Dokumentu Objektu Modeloa) oinarritutako XSS-an, kode gaiztoa zuzenean exekutatzen da bezeroaren aldean, nabigatzailean DOM-a manipulatzen, zerbitzariarekin interakziorik izan gabe. Horrela, orrialdearen eduki dinamikoa manipulatu edo aldatu egiten da, bezeroan JavaScript kodea exekutatuz, orrialdeko parametro edo eremu horietan, ondo kodifikatu edo balidatu ez direnak. Horrela, manipulatutako orrialdea exekutatuko duten erabiltzaile guztiak erasoa jasango dute.

Adibideko aplikazioan, erabiltzaile batek webgunean saioa hasi duenean, ongietorri-hizkuntza bat erakusten zaio trantsizio gisa, saioa hasi duen erabiltzailearen izena zuzenean eta balidatu gabe injetatzen ari dena, ongietorri-mezua edukitzeko helburua duen HTML objektuaren .innerHTML batean.

Hori .innerHTML manipulatu daiteke dagokion script-a inyectatuz, hala nola erantzunaren DOM-a aldatu dadin, exekuzio-denboran, bezeroaren nabigatzailean:

Eta administratzaileen saio-cookiea lapurtzen du, erasotzailearen zerbitzarian ikus daitekeen moduan:

"Ongi etorri mezua administrazio paneletik birbideratzen denez, bi segundo igaro ondoren, administratzaileak ez du bere saio cookiea lapurtu dela jabetuko."

Konbinatutako erasoak: CSRF tokenaren saihestea XSS ahultasunaren bidez

Adibideko aplikazioan, administrazio panela (users_mgmt.php) dago, webguneko administratzaileak (user admin) bakarrik kudeatua:

Beharretako eremua XSS-rako ahultasun bat da. Erabiltzaile bakoitzak bere profila aldatu dezake, saioa hasi ondoren bere profil aldaketa orrian, user_edit.php (pasahitza barne).

Kodearen xehetasuna behatzen bada, web orriak CSRF/XSRF (Cross-Site Request Forgery) erasoei aurrea hartzen dien token bat du.

"BurpSuiteko sekuentziatzailea erabiliz, token hauen indarra eta aleatorioa aztertzen bada, ondorio batera irits daiteke, hau da, token hau nahikoa sendoa eta fidagarria dela, erraz asmatzeko ahaleginak egiteko, indar brutuz erasotzeko aukera izatetik oso urrun."

2260 token aztertu dira, eta horietako inor ez zen behin ere errepikatu.

Hala ere, aurretik aurreratu den bezala, behaketa-eremua XSS-rako ahul da. Hori gertatzen bada, ez du axola erabiltzen den tokenaren indarra edo ausazkotasuna: orria CSRF-rako ahul izango da, babestuta egon arren.

Hala ere, injezio hau behaketa eremuan abusatu daiteke, orrialdeko token (anti) CSRF irakurtzen duen script bat sortzeko eta hori saihesteko laguntzeko, adibidez, administratzaile erabiltzailearentzako pasahitz aldaketa bat exekutatuz (ohartu, erregistroaren identifikatzailea id batek ematen duela, eta id hau erabiltzaileen kudeaketan erabiltzen dela, erabiltzaile bakoitza editatzeko, administratzailea barne (presumiblemente, taulan identifikatzailea 1, "hacker" erabiltzaileak identifikatzailea 6 duelako).

Horrela, erabiltzaileak "hacker" Burp-ekin harrapatuz eta aldaketarako eskaerak aztertuz, esaterako, hurrengo script-a sortu dezake, DOM-a dinamikoan egungo token-a harrapatzeko, eta horrekin "admin" erabiltzailearen pasahitza aldatzeko, kontua lapurtuz:

Horrela, script-a Observations eremuan sartuz:

lortuko litzateke, erabiltzaileak "administratzailea" erabiltzaile kudeaketara sartzean, script-a aktibatzea, ez jakin, automatikoki pasahitza aldatuko duena, "hacker" erabiltzaileak bere kontua lapurtzea ahalbidetuz:

Une honetan, "hacker" erabiltzaileak administratzailearen kontura eta pasahitz berrira sartu ahal izango du...

Ondorioa

Inoiz ez da azpimarratu behar XSS injezioen indarra, izan ere, arazo larriak sor ditzakete, baita web zerbitzari osoaren kontrola hartzea ere, gunean dauden beste ahultasun batzuekin ondo konbinatzen bada.

Prebentzio neurriak

XSSaren zuzeneko murrizketa bat lortzeko, web aplikazioen garapenean praktika onen serie bat aplikatu beharko litzateke:

Zerbitzari eta bezero aldetako balidazioa

Ez da nahikoa erabiltzailearen sarrerako eremu edo parametroen balidazioak bezeroan aplikatzea, kontrol horiek saihestu daitezkeelako (bezeroan balidazioak saihestuz, dagokion script-a omituz). Zerbitzarian balidazio egokia izatea beharrezkoa da, sartutako datuak (edo web proxy baten bidez atzemandako eta manipulatutakoak) balidatuz, arriskutsuak izan daitezkeenak edo aplikazioaren funtzionalitate zehatzari egokitzen ez direnak baztertuz.

Funtzioen aplikazio egokia ihes egiteko eta kodifikatzeko

Erabiltzaileak sartutako datuen kodifikazioa zuzena dela ziurtatu behar da, datuak nabigatzaileak interpretatu aurretik, "arriskutsuak" diren karaktereak ihes eginez, horretarako erabilitako zerbitzariaren hizkuntzan dagoen funtzionalitatearen bidez. Adibidez, PHPn htmlspecialchars edo htmlentities bezalako funtzionalitateak daude, zeinak zenbait karaktere (edo azken kasuan, posible guztiak) HTMLn beren baliokideetara ihes egiten duten. Neurri hauek berez ez dira %100 fidagarriak, ihes egiteko neurriak daudelako, baina gainerakoekin eta balidazio ona batekin konbinatuta, aukera defentsibo ona dira.

"zerrenda zurien" erabilera

Zerrenda zuriak erabiltzea zenbait karaktere edo erregistratutako adierazpenen erabilera baztertzen duten zerrenden erabileraren aurrean. Beti hobe da informazio jakin baten erabilera baimentzea, beste baten erabilera baztertzea baino, beti saihesteko edo ordezkatzeko sistema bat bilatu daitekeelako. Hori beti kontuan hartu beharko litzateke WAF (Web Application Firewall) ezartzerakoan.

DOM (Dokumentu Objektu Modeloa) era dinamikoan eraikitzeko saihesteko metodoen erabilera

Betebehar da beti seguruak diren metodoak erabiltzea, JavaScript bidez DOM-ean datu balidatuak ez direnak sartzea saihesteko, adibidez setAttribute edo textContent erabiltzea, innerHTML-ren ordez.

Segurtasun buruak erabilera

Edukien Segurtasun Politika (CSP)

"Segurtasun goiburu haurekin, web aplikazioan exekutatu daitezkeen baliabide motak murrizteko eduki segurantza politika bat ezartzea, malware scripten injezioa saihestuz edo blokeatuz."

Edukien Segurtasun Politika: lehenetsitako-iturria 'berea'; script-iturria 'berea' http://example.com; objektu-iturria 'bat ere ez'

>Aurretik emandako kodeak baliabideak soilik zerbitzariaren jatorri berekoa kargatzea ahalbidetuko du, jatorri bereko script-ak edo https://example.com webgune faltsua kargatzea baimentzen duela, eta guztiz blokeatzen du embed, object edo applet motako objektuen karga, eraso-atalak izan daitezkeenak.

X-Content-Type-Options

Edukien analisiaren (MIME sniffing) gaineko erasoei ekiditea, modu horretan script gaiztoak exekutatu ahal izateko:

X-Content-Type-Options: no-sniff

X-XSS-Babesa

"Aktibatu goiko burua erabiliz XSS iragazkia, zenbait nabigatzaileek gaiztozko script batzuk exekutatzea prebenitzeko erabiltzen duten iragazkia. Aurreko buruekin konparatuz segurtasunean ez da hain sendoa, baina neurri osagarri erabilgarria da: iragazkia aktibatuta dago eta XSS erasoa detektatzen bada, nabigatzaileak scriptaren exekuzioa blokeatzen du, edukia garbitu beharrean (halere, beti aplikatu beharko lirateke zerbitzari mailako garbiketa neurriak)"

X-XSS-Protection: 1; modua=blokeatu

X-Frame-Aukerak

Ordezkatze espresuaren bidez, orri hau X-Frame batean txertatzea debekatuta dago, clickjacking erasoei aurrea hartzen zaie, XSS-rekin konbinatu daitezkeenak, iframe batean txertatutako script gaizto bat exekutatzen duen erasotzaile orri bat barne.

X-Frame-Options: DEKATU

Cross-Origin Resource Sharing (CORS)

CORS goiburua erabiliz, zein domeinek egin dezaketen eskaerak web zerbitzariaren aurka beste jatorritik kontrolatzen da. Modu egokian konfiguratutakoan, baliabide sentikorretara sarbidea mugatu dezake leku gaiztoetatik (XSS eta SSRF konbinazioak barne, etab.).

Access-Control-Allow-Origin: http://example.com

Cache-Kontrola

Cache biltegiratzeko konfigurazio oker bat erabiltzen bada, eduki kaltegarria edo sentikorra modu segurtuan biltegiratzeko aukera emango da. Horrela, burua egoki konfiguratzen bada, erantzun jakin batzuen bidez exekutatuko den eduki dinamiko bat cachean biltegiratzen ez dela saihestu daiteke.

Cache-Control: ez-denda, ez-cache, berriro-egiaztatu behar

Erreferentea-Politika

Nahiz eta goiburua hau XSS-rekin zuzenean lotuta ez egon, nabigatzaileak Referrer goiburuan zati gisa informazio jakin bat bidaltzen badu, erasotzaile batek informazio hori aprobetxatu dezake goiburuan agertzen diren URLen datu sentikor batzuk ustiatzeko, zeinek batzuetan injetagarriak diren parametroak barne hartzen dituzten, XSS bat ustiatzeko, adibidez.

Itzuli blogera