Hva er CSRF?

CSRF, cross-site reference attack, one-click attack, sidejacking eller session riding, kjært barn har mange navn. Angrepet baserer seg på at uønsket kode kjører i brukerens nettleser og utfører handlinger i en webapplikasjon på vegne av brukeren.

Selve angrepet utføres gjerne ved at brukeren lures til å laste en side med ondsinnet innhold. Innholdet benytter seg av det faktum at brukeren gjerne er innlogget og autentisert mot en tjeneste, og koden vil nå kunne benytte seg av brukerens identitet og rettigheter i webapplikasjonen.

Et eksempel:

sett at koden under er en gyldig request for å utføre en transaksjon i en nettbank.

GET http://ikketrykk.com/transfer.do?acct=BOB&amount=100 HTTP/1.1

som angriper kan jeg benytte meg av dette ved å lure offeret til å klikke på en link som utfører koden over.

<a href="http://ikketrykk.com/transfer.do?acct=MARIA&amount=100000">Klikk for å laste ned mange kule ting</a>

om offeret nå klikker på lenken, samtidig som han er innlogget i den aktuelle nettbanken, så vil angrepet lykkes. Merk at lenken er kamuflert som "Klikk for å laste ned mange kule ting".

CSRF Angrep

Som vist i eksempelet over er angriper ofte avhengig av at brukeren faktisk klikker lenken som utfører den ondsinnete handlingen. Dette er en av grunnene til at du skal tenke deg godt om før du klikker på lenker i epost fra folk du ikke venter epost fra. Tar man koden i eksempelet over og legger inn i en epost vil det kun vises som "Klikk for å laste ned mange kule ting" lenke. Dette er et typisk phishing angrep, og det er forbausende mange som faktisk klikker på ting de ikke burde klikket på!

Om webapplikasjonen tillatet GET forespørsler kan den ondsinnete koden gjemmes i en <img> tag, noe som fører til at angrepet blir utført uavhengig av om offeret klikker eller ikke.

Eksempel på bruk av img tag:

<img src="http://ikketrykk.com/transfer.do?acct=MARIA&amount=100000" width="1" height="1" border="0">

i eksempelet over vil offeret kun se et kryss / "manglende bilde ikon", og angrepet er utført. Dette er en av grunnene til at du ikke ønsker å laste bilder automatisk i ditt epostprogram.

CSRF angrep er mulig fordi at en webapplikasjon autentiserer selve nettleseren og ikke brukeren. Etter at brukersesjonen er autentisert vil webapplikasjonen ikke ha noen mulighet for å kontrollere om det er den samme brukeren som gjør de etterfølgende forespørslene, eller noen andre.

CSRF utnytter det faktum at webapplikasjonen stoler på brukeren, i motsetning til XSS som utnytter at brukeren stoler på webapplikasjonen. Det er heller ikke noen automatikk i at tiltak mot xss også fungerer mot csrf.

Tiltak mot CSRF

For at et csrf angrep skal være vellykket må brukeren være autentisert mot webapplikasjonen, og angriper kan ofte ikke utføre andre handlinger en de som den autentiserte brukeren kan. En kan altså begresnse angrepet ved å være flink å logge ut av websider når man ikke bruker de, samt å holde kontoer adskilt. Er det en spesifikk webside / webapplikasjon hvor du har mye rettigheter så jobber du med denne i en separat nettleser, som kun brukes til akkurat dette og ingenting annet.

Man kan begrense alle GET forespørsler slik at de kun får lese data, men ikke endre data på serveren. Dette vil hindre <img> tagger og andre typer angrep via GET forespørsler som vist i eksemplene over.

Man kan legge til en pseudorandom kode i alle POST forms. Denne pseudorandom koden må da sendes fra klienten tilbake til serveren som endel av POST forespørslen. Serveren kan da kontrollere om koden som kommer inn via en POST forespørsler matcher med den opprinnelige POST formens kode.

Man kan sjekke referrer feltet i HTTP forespørslen. Om referrer peker til en annen side bør hele HTTP forespørslen avvises. Dette vil at hindre at angriperen kan legge ondsinnet kode på sin side for å utføre handlinger på din side. Nå må angriperen faktisk greie å lagre angrepskoden på din side, f.eks som stored xss i forumet ditt eller noe tilsvarende.