Cross-Site Scripting - Hvordan hackere kapre din side

Tobias Schüring Senest opdateret den 15.
6 Min.
På tværs af Scripting_XSS

XSS, SQL-injektion, XMLrpc - hvis en WordPress sikkerhedsopdatering, indeholder opdateringsrapporterne hovedsageligt kryptiske forkortelser. Selv om det er klart, at disse opdateringer er nødvendige, og den ekstra sikkerhed er meget glædeligt, det er vigtigt at forstå, hvad der ligger bag disse sårbarheder. For kun hvis du forstår de huller, som opdateringerne udfylder, kan du også træffe en informeret beslutning. Derfor er vi i dag dedikeret til scripting på tværs af webstedet, eller XSS, langt det mest almindelige komplekse angreb på WordPress Sider.

Hackerangreb kan nemt sammenlignes med indbrudstyve. Brute Force Angreb er mere ligner metoden til koben. Den kriminelle modstår værktøjet, indtil døren eller vinduet åbnes. Angreb på XSS sårbarheder, på den anden side, er sofistikerede: indbrudstyven ved præcis, hvor du skal begynde og gevinster målrettet adgang til den ene side.

I løbet af cross-site scripting, sikkerhedshuller i hjemmesider udnyttes således på en målrettet måde. Hackere infiltrere ondsindede scripts i en betroet sammenhæng (dine sider!). Svarende til en blind passager på et skib, denne skadelig kode bruger dit websted som et køretøj til at forfølge sine egne mål.

I værste fald giver dette angribere fortrolige oplysninger eller adgang til den beskadigede brugers computer. Sådanne angreb er ikke ualmindelige: lidt over halvdelen af angrebene Wordfence sårbarheder, der blev fundet i 2015 og 2016 i Plugins var sårbarheder på tværs af webstedets scripting. Ofte danner et XSS-angreb "base" for yderligere angreb, såsom spam, phishing eller endda DDoS-angreb. Det er derfor, jeg viser dig i dag, hvordan præcis cross-site scripting værker, hvilke typer af angreb der er, og hvor farlige angrebene er.

Scripting på tværs af websteder fungerer altid på samme måde: Et hul fører skadelig kode til din side

Scripting på tværs af websteder er en risiko, når et webprogram videresender brugerdata, der indtastes i webbrowseren, uden at kontrollere, om der findes scriptkode. Et godt eksempel på en sådan web-applikation er en support chat.

De ondsindede scripts kan bruges til at få adgang til serveren via selve webprogrammet. Derfra, den skadelige kode vil før eller senere lander med de berørte kunder. Et godt eksempel på en sådan XSS sårbarhed er den, der blev opdaget i juli 2016Bug i billedet metainfos i WooCommerce 2.6.2. En fejl gjorde det muligt for angribere at indsprøjte HTML-kode i metadescripterne af billeder udefra. Enhver kunde, der ville have kigget på det pågældende billede (f.B. ved at klikke på billedet) ville være i fare for at blive angrebet. For eksempel, en hacker kunne have inficeret dine kunders computere med en virus.

Populært trick i cross-site scripting: Manipulerede former

XSS kan også tillade hackere at erstatte harmløse former med manipulerede former. Disse formularer derefter indsamle data fra ofrene (din side besøgende!). Afden måde, SSL kryptering kan heller ikke beskyttes. Da HTTPS betyder "kun", at forbindelsen mellem serveren og klienten er krypteret. Men hvis selve formularen er ændret, vil en krypteret forbindelse ikke fungere.

Som med andre typer af angreb, målet for hackere er i de fleste tilfælde at tjene penge på deres rænkespil. Konkret betyder det, at angriberne enten stjæler data, som de senere sælger, eller ønsker at inficere sider for at integrere dem i et såkaldt botnet, som derefter udlejes.

3 typer af XSS: reflekteret, vedvarende og lokale XSS

Scriptangreb på tværs af steder kan groft inddeles i tre typer:

Groft sagt udføres XSS-angreb som følger: Skadelig kode injiceres, hvor der forventes brugerinput (f.eks. i en intern søgning). Som en del af serverens svar, den skadelige kode udføres derefter af klienten, dvs i brugerens browser. Og det er præcis her, de respektive skader er forårsaget, dvs brugerdata er stjålet.

Reflekterende scripting på tværs af webstedet

Nogle indgange, f.eks. Det betyder f.eks., at siden efter at have skrevet "Test" i søgefeltet udsender "Du søgte efter test". Så hvad brugeren indtaster bliver en del af serverens svar.

Dette er præcis, hvad angriberne behændigt udnytte: Hvis et skadeligt script sendes til webserveren i stedet for et søgeord, kan siden manipuleres på en sådan måde, at det i sidste ende udfører det. Denne type angreb er også kendt som ikke-vedvarende. Den skadelige kode er således kun midlertidigt injiceres i den respektive side, men ikke gemt.

I juli 2019 Plugin WP Statistik fundet en sådan sårbarhed (og fast det på samme dag!). En inputværdi på wps_visitors_page blev videresendt ukontrolleret, hvilket resulterede i en sårbarhed på grund af reflekteret XSS. blive hacket, hvis en administrator tidligere havde klikket på et tilsvarende manipuleret link

Dette er, hvad en reflekteret cross-site scripting angreb kan se ud .B.
Dette er, hvad en reflekteret cross-site scripting angreb kan se ud .B.

Sådan fungerer det:Angriberen spreder forbindelser med manipulerede parametre til sine potentielle ofre. Uden at vide det, brugeren sender en "manipuleret" anmodning til serveren ved at klikke på linket, og den skadelige kode kører sammen med serverens svar. Fordi, i modsætning til den vedvarende XSS, koden er ikke gemt nogen steder, hackeren skal distribuere det en masse til potentielle ofre. Dette kan for eksempel ske via e-mails eller sociale netværk.

Vedvarende scripting på tværs af webstedet

Med vedvarende eller vedvarende XSS gemmes de skadelige scripts på webserveren og leveres, hver gang en klient kalder dem. Forudbestemt til dette er web-applikationer, der gemmer brugerdata på serversiden og derefter udskrive det uden verifikation eller kodning (f.eks fora). Denne type scripting kan være særligt farligt for højfrekvente blogs og fora, som malware kan spredes hurtigt her på grund af det store antal brugere.

Denne grafik viser en mulig strøm af et vedvarende scriptangreb på tværs af webstedet.
Udløbet af et vedvarende scriptangreb på tværs af webstedet. Kilde: Blog SAP

Foreksempel er jegn etforum, bogførte stillinger gemt i en database. Disse gemmes ofte ukontrolleret og ukrypteret. Angribere drage fordel af denne mulighed og tilføje et skadeligt script (e.B. ved hjælp af en kommentar) til en normal forum indlæg. Brugerne modtager det respektive link til stillingen enten via e-mail eller tilfældigt ankommer til den tilsvarende post og udføre scriptet med indkaldelsen af stillingen. Fordel for hackeren: Han kan nu "spionere" på berørte kunder eller tilføje dem til hans botnet for yderligere angreb.

DOM-baseret eller lokal scripting på tværs af webstedet

I modsætning til vedvarende og reflekteret XSS fungerer DOM (Document Object Model) ved at udføre scripts på klientsiden. Det betyder, at serveren er uvidende om et sådant angreb og server-side sikkerhedsforanstaltninger hjælper ikke.

Et velkendt eksempel på en sådan mangel er tilfældet med genericon-pakken. Genericon-pakken er et ikonsæt, der er Plugins , herunder Jetpack. Via en HTML-fil i dette ikon sæt var det muligt at injicere tilsvarende skadelig kode.

Efter indtastning af denne URL-adresse, en javascript alarm dukkede op. Dette er bevis på, at indtastet javascript-kode kan bruges til at manipulere den respektive side.
Når du har indtastet denne URL-adresse, vises en JavaScript-besked. Dette er et bevis på, at indtastet JavaScript-kode kan bruges til at manipulere den respektive side. Kilde: securityaffairs.co

Men, en DOM-baseret XSS angreb kræver, at brugeren til at klikke på en kompromitteret URL. Ved at kalde denne URL-adresse, den skadelige kode kan udføres gennem et hul i en klient-side script. Blandt andet, det faktum, at et link skal klikkes først gør DOM-baserede XSS en lidt vanskeligere og derfor mindre sandsynligt type angreb.

Grafikken viser en mulig strøm af et lokalt scriptangreb på tværs af webstedet.
Et eksempel på et lokalt scriptangreb på tværs af webstedet. Kilde: heise.de

Eksempel: Brugeren klikker på den manipulerede WEBADRESSE og sender en anmodning til webprogrammet. Dette svarer ved at overføre scriptkoden (som er beskadiget, men ikke ændret) til browseren for at begynde at køre scriptet. De manipulerede parametre fra URL-adressen fortolkes og udføres nu i brugerens browser som en del af scriptet. Den webside, der vises i browseren er således ændret, og brugeren nu ser den manipulerede side uden at vide det.

Konklusion: Ganske almindelig og ikke harmløs, derfor passende beskyttelse er vigtig

XSS sårbarheder er en af de mest almindelige gateways for skadelig kode nogensinde. Og ofte danner et tilsvarende angreb grundlaget for yderligere angreb, såsom spam, phishing eller endda DDoS-angreb. Angribere kapre din side og misbruge det til at nå deres egne mål.

Reflekterende og vedvarende XSS er særligt almindelige, fordi lokal scripting på tværs af webstedet er mere kompleks og vanskelig at implementere. Sider, der videresender indtastede brugerdata til webbrowseren uden at kontrollere, om der er nogen skadelig kode, er særligt sårbare. At finde sådanne huller er ikke så let. I princippet er det netop sikkerhedsudbydernes opgave, såsom sucuri og co, som konstant udvikler deres sikkerhedsforanstaltninger.

Men selvfølgelig er der også for normal WordPress -brugerne har mulighed for at beskytte sig mod disse angreb.Opdateringer af alle WordPress komponenter er e..B. en enkel, men meget effektiv foranstaltning. Hvordan du kan forhindre cross-site scripting som et websted operatør, men også som en internetbruger, forklarer vi i vores næste artikel om emnet.

Har du kommentarer eller spørgsmål? Så bare efterlade en kommentar!

Som systemadministrator overvåger Tobias vores infrastruktur og finder alle justeringsskruer for at optimere vores serveres ydeevne. På grund af hans utrættelige indsats, er han ofte også Slack findes.

Lignende artikler

Kommentarer til denne artikel

Skriv svar på en

Din e-mailadresse vil ikke blive offentliggjort. Obligatoriske felter er markeret med *.