Websårbarheder er udbredte og stiger konstant. Det er vigtigere end nogensinde før at opretholde brugernes sikkerhed og privatlivets fred. Hvis du ikke tager fat på web-sårbarheder, kan det føre til et ødelagt omdømme og store bøder fra myndighederne, og du vil også miste dine brugeres tillid.
Websteder og webapplikationer er sårbare over for malware, spam og andre angreb – denne artikel fokuserer på en af disse angrebsvektorer – CSRF-angreb (Cross-Site Request Forgery). CSRF-angreb er særligt bekymrende, fordi de kan finde sted uden brugerens viden. De er også svære at opdage for en udvikler eller ejeren af et websted, fordi de ondsindede anmodninger ligner ægte anmodninger meget.
Denne artikel undersøger et CSRF-angreb, hvordan det fungerer, og hvilke skridt du kan tage for at forberede dig på et CSRF-angreb.
Se vores videoguide for at forstå alt om CSRF-angreb
Hvad er et CSRF-angreb?
Et Cross-Site Request Forgery-angreb, også kendt som et CSRF-angreb, narrer en autentificeret bruger til at udføre utilsigtede handlinger ved at sende ondsindede anmodninger, uden at de er klar over det.
Typisk involverer et CSRF-angreb statsændring af anmodninger, fordi angriberen ikke modtager et svar. Eksempler på sådanne anmodninger omfatter sletning af en post, ændring af en adgangskode, køb af et produkt eller afsendelse af en besked. Disse kan alle ske uden brugerens viden.
Den ondsindede angriber bruger typisk social engineering til at sende en intetanende bruger et link via chat eller e-mail.
Når brugeren klikker på linket, udfører den de kommandoer, som angriberen har indstillet.
Hvis man f.eks. klikker på et link, kan man overføre penge fra en brugers konto. Eller det kan ændre en brugers e-mail-adresse og forhindre brugeren i at få adgang til sin konto igen.
Hvordan fungerer et CSRF-angreb?
Det første og mest afgørende skridt i et CSRF-angreb er at få brugeren til at initiere en forespørgsel om ændring af tilstand, mens han er logget ind. Med CSRF-angreb forsøger angriberen at få en autentificeret bruger til ubevidst at sende en ondsindet webanmodning til et websted eller en webapplikation. Disse anmodninger kan bestå af cookies, URL-parametre og andre datatyper, der ser normale ud for brugeren.
For at et CSRF-angreb kan lykkes, skal følgende betingelser være opfyldt:
- En autentificeret bruger skal være logget ind på en webapplikation, der bruger cookies til sessionshåndtering.
- En angriber skal oprette en forfalsket forespørgsel med tilstandsændring.
- Ægte anmodninger, der håndteres af målserveren, må ikke indeholde uforudsigelige parametre. Anmodningen må f.eks. ikke forvente et password som en parameter til kontrolformål, før den tilstandskiftende anmodning igangsættes.
Den mest almindelige metode til at gennemføre CSRF-angreb er at bruge cookies i programmer med en svag SameSite-cookiepolitik. Webbrowsere inkluderer cookies automatisk og ofte anonymt, og de gemmer cookies, der anvendes af et domæne, i enhver webanmodning, som en bruger sender til det pågældende domæne.
SameSite-cookiepolitikken definerer, hvordan browseren i forbindelse med browsing på tværs af websteder behandler cookien. Hvis den er indstillet til strict, deles cookien ikke i browsingkontekster på tværs af websteder, hvilket forhindrer CSRF-angreb. Hvis den er indstillet til ingen, vedhæfter browseren cookien i alle sammenhænge på tværs af websteder. Dette gør programmet sårbart over for CSRF-angreb.
Når en bruger ubevidst indsender en ondsindet anmodning via en webbrowser, får de gemte cookies anmodningen til at fremstå legitim over for serveren. Serveren reagerer derefter på anmodningen ved at ændre brugerens konto, ændre sessionstilstanden eller returnere de ønskede data.
Lad os se nærmere på to eksempler på CSRF-angrebsmuligheder, den ene med en GET-anmodning og den anden med en POST-anmodning.
CSRF for en GET-anmodning
Først skal vi se på en GET-anmodning, der anvendes af en webapplikation til finansielle bankforretninger, hvor angrebet udnytter en GET-anmodning og levering af hyperlinks.
Lad os antage, at GET-anmodningen til overførsel af penge ser nogenlunde sådan ud:
GET https://xymbank.com/online/transfer?amount=1000&accountNumber=547895 HTTP/1.1I den ægte anmodning ovenfor anmoder brugeren om at overføre 1 000 USD til en konto hos 547895 som betaling for købte produkter.
Selv om denne anmodning er eksplicit, enkel og praktisk, udsætter den kontohaveren for et CSRF-angreb. Det skyldes, at anmodningen ikke kræver detaljer, som en angriber måske ikke kender. Så for at iværksætte et angreb skal en angriber blot ændre denne anmodnings parametre (beløbet og kontonummeret) for at skabe en eksekverbar forfalsket anmodning.
Den ondsindede anmodning ville være effektiv på alle bankens brugere, så længe de har igangværende cookie-administrerede sessioner.
Sådan ville den forfalskede anmodning om at overføre 500 USD til en hackers konto (her nummer 654585) se ud. Bemærk, at eksemplet nedenfor er en stærkt forenklet version af de trin, der indgår i et CSRF-angreb til en forklaring.
GET https://xymbank.com/online/transfer?amount=500&accountNumber=654585 HTTP/1.1Når det er gjort, skal angriberen finde en måde at narre brugeren til at sende denne anmodning, mens han er logget ind på sin netbankapplikation. En af måderne at gøre dette på er at skabe et harmløst hyperlink, der får brugerens opmærksomhed. Linket kan se således ud:
<a
href="https://xymbank.com/online/transfer?amount=500&accountNumber=654585">Click here to get more information</a>.Da angriberen har fundet de korrekte e-mailadresser på sine mål, kan han sende dette via e-mail til mange bankkunder. De, der klikker på linket, mens de er logget ind, vil udløse anmodningen om at sende angriberen 500 dollars fra den loggede konto.
CSRF for en POST-anmodning
Lad os se, hvordan den samme finansielle institution ville opleve en CSRF, hvis de kun accepterede POST-forespørgsler. I dette tilfælde ville den hyperlinklevering, der blev brugt i eksemplet med GET-forespørgslen, ikke fungere. Derfor ville et vellykket CSRF-angreb kræve, at en angriber opretter en HTML-formular. Den ægte anmodning om at sende 1.000 dollars for et købt produkt ville se således ud:
POST /online/transfer HTTP/1.1
Host: xymbank.com
Content-Type: application/x-www-form-urlencoded
Cookie: session=FRyhityeQkAPzeQ5gHgTvlyxHJYhg
amount=1000
account=547895Denne POST-anmodning kræver en cookie til at bestemme brugerens identitet, det beløb, han/hun ønsker at sende, og den konto, han/hun ønsker at sende. Angribere kan ændre denne anmodning for at udføre et CSRF-angreb.
Angriberen skal blot tilføje en ægte cookie til en forfalsket anmodning for at få serveren til at behandle overførslen. Det kan de gøre ved at oprette et hyperlink med et harmløst udseende, der fører brugeren til en udløsende webside, der ser således ud:
<html>
<body>
<form action="https://xymbank.com/online/transfer" method="POST">
<input type="hidden" name="amount" value="500"/>
<input type="hidden" name="account" value="654585" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>Vi har allerede indstillet parametrene for beløb og konto i formularen ovenfor. Når en autentificeret bruger besøger siden, tilføjer browseren sessioncookien, inden den videresender anmodningen til serveren. Serveren videresender derefter 500 dollars til hackerens konto.
3 måder at afværge CSRF-angreb på
Der er flere metoder til at forhindre og drastisk afbøde potentielle CSRF-angreb på dit websted eller din webapplikation, herunder:
- Brug af CSRF-tokens
- Brug af referrer-headeren
- Valg af en hostingløsning med fokus på sikkerhed, som Kinsta
Sådan forhindrer du CSRF-angreb ved hjælp af CSRF-tokens
Et CSRF-sikkert websted tildeler hver session et unikt token og deler det med serversiden og klientbrowseren. Når en browser sender en følsom anmodning, forventer serveren, at den indeholder det tildelte CSRF-token. Hvis den har det forkerte token, afviser serveren den. CSRF-tokenet gemmes af sikkerhedshensyn ikke i sessioncookies i klientens browser.
Potentielle sårbarheder ved CSRF-tokens
Selv om CSRF-tokens er en fremragende sikkerhedsforanstaltning, er denne metode ikke angrebssikker. Nogle af de sårbarheder, der er forbundet med CSRF-tokens, omfatter bl.a:
- Valideringsomgåelse – Nogle programmer springer verifikationstrinnet over, hvis de ikke finder et token. Hvis en angriber får adgang til kode, der indeholder et token, kan vedkommende fjerne dette token og udføre et CSRF-angreb med succes. Så hvis en gyldig anmodning til en server ser således ud:
POST /change_password
POST body:
password=pass123&csrf_token=93j9d8eckke20d433En angriber behøver blot at fjerne tokenet og sende det således for at udføre angrebet:
POST /change_password
POST body:
password=pass123-
Samlede tokens — Nogle programmer opretholder en pulje af tokens til validering af brugersessioner i stedet for at udpege et specifikt token til en session. En angriber behøver kun at få fat i et af de tokens, der allerede findes i puljen, for at udgive sig for at være en af webstedets brugere.
En angriber kan logge ind på et program ved hjælp af sin konto for at få et token, f.eks:
[application_url].com?csrf_token=93j9d8eckke20d433Og da tokens er samlet i en pulje, kan angriberen kopiere og bruge det samme token til at logge ind på en anden brugers konto, da du vil bruge det igen:
- CSRF’er kan være token kopieret til cookien – Nogle applikationer kopierer de parametre, der er relateret til et token, til en brugers cookie. Hvis en angriber får adgang til en sådan cookie, kan vedkommende nemt oprette en anden cookie, placere den i en browser og udføre et CSRF-angreb.
En angriber kan således logge ind på en applikation med sin konto og åbne cookie-filen for at se følgende:
Csrf_token:93j9d8eckke20d433De kan derefter bruge disse oplysninger til at oprette en anden cookie for at fuldføre angrebet
- Ugyldige tokens – Nogle applikationer matcher ikke CSRF-tokens til en brugersession. I sådanne tilfælde kan en angriber virkelig logge ind på en session, få et CSRF-token svarende til ovenstående og bruge det til at iværksætte et CSRF-angreb på et offers session.
Sådan forhindrer du CSRF-angreb med Referrer Header
En anden strategi til forebyggelse af CSRF-angreb er at bruge referrer-headeren. I HTTP angiver referrer-headere forespørgslernes oprindelse. De bruges typisk til at udføre analyser, optimering og logning.
Du kan også aktivere kontrol af referrer-headere på serversiden for at forhindre CSRF-angreb. Serversiden kontrollerer forespørgslens kildeoprindelse og bestemmer forespørgslens måloprindelse. Hvis de stemmer overens, er anmodningen tilladt. Hvis der er en uoverensstemmelse, dropper serveren anmodningen.
Det er meget nemmere at bruge referrer-headers end at bruge tokens, fordi det ikke kræver individuel brugeridentifikation.
Potentielle sårbarheder ved Referrer Header
Ligesom CSRF-tokens har referrer-headers nogle betydelige sårbarheder.
For det første er referrer-headere ikke obligatoriske, og nogle websteder sender anmodninger uden dem. Hvis CSRF ikke har en politik til at håndtere anmodninger uden headere, kan angribere bruge anmodninger uden header til at udføre tilstandsændringsangreb.
Desuden er denne metode blevet mindre effektiv med den nylige indførelse af referrer-politikken. Denne specifikation forhindrer URL-lækage til andre domæner og giver brugerne mere kontrol over oplysningerne i referrer-headeren. De kan vælge at afsløre en del af oplysningerne i referrer-headeren eller deaktivere dem ved at tilføje et metadata-tag på HTML-siden, som vist nedenfor:
<meta name="referrer" content="no-referrer">Ovenstående kode fjerner referrer-headeren for alle anmodninger fra denne side. Dette gør det vanskeligt for programmer, der er afhængige af referrer-headere, at forhindre CSRF-angreb fra en sådan side.
Sådan beskytter Kinsta mod CSRF-angreb
Ud over at bruge referrer-headeren og CSRF-tokens er der en tredje og langt nemmere mulighed: At vælge en sikker hosting-tjeneste som Kinsta til dine websteder og webapplikationer giver en meget stærkere og mere sikker barriere mellem angribere og dine brugere.
Ud over kritiske sikkerhedsfunktioner som automatiske backups, to-faktor-autentifikation og SFTP over SSH-protokoller giver Kinstas Cloudflare-integration beskyttelse på virksomhedsniveau med IP-baseret beskyttelse og firewallbeskyttelse.
Specifikt har Kinsta i øjeblikket omkring 60 brugerdefinerede firewallregler, der hjælper med at forhindre ondsindede angreb og håndtere alvorlige uautentificerede sårbarheder i plugins og temaer, herunder specifikke regler, der leder efter CSRF-sårbarheder.
Opsummering
Cross-site request forgery (CSRF) er et angreb, der narrer autentificerede brugere til utilsigtet at initiere anmodninger om tilstandsændring. De er rettet mod applikationer, der ikke kan skelne mellem gyldige og forfalskede anmodninger om tilstandsændring.
CSRF kan kun lykkes i programmer, der er afhængige af session-cookies til at identificere loggede brugere og har en svag SameSite-cookiepolitik. De har også brug for en server, der accepterer anmodninger, som ikke indeholder ukendte parametre som f.eks. adgangskoder. Hackere kan sende ondsindede angreb ved hjælp af enten GET eller POST.
Selv om brugen af CSRF-tokens eller håndhævelse af referrer header-verifikation kan forhindre nogle CSRF-angreb, har begge foranstaltninger potentielle sårbarheder, som kan gøre dine forebyggende foranstaltninger ubrugelige, hvis du ikke er forsigtig.
Ved at migrere til en sikker hostingplatform som Kinsta sikrer du dine websteder eller webapps mod CSRF-angreb. Desuden forhindrer Kinsta’s integration med Cloudflare specifikke CSRF-angreb.
Skriv et svar