Det er ikke noget vi nødvendigvis tænker på – når vi i vores daglige rutine bevæger os fra site til site, men det at vi i browseren har gemt vores identitet fra besøg til besøg gør at vi er sårbare over for CSRF-angreb. Problemet er at angrebet er næsten usynligt da det kan være drevet af noget så banalt som et image-tag eller en knap indlejret på et andet website.
Også for ejeren af det site der bliver angrebet er handlingen næsten usynligt – IP adresse, browser identifikation og andre parametre vil se ud som om at det er den rigtige bruger der udfører handlingen.
Angrebet
De fleste websites bruger kun én mekanisme til at bestemme autenticitet af en handling. I mange tilfælde er det vha. en cookie der sendes med på hver eneste forespørgsel. CSRF går ud på at udnytte denne mekanisme til at lave forespørgsler på vegne af ofret. Oftest er slutresultatet en eller anden form for ændring af tilstand på det ramte site – fx. skift af password, videresendelse af følsomme oplysninger eller sågar overførsel af penge.
Angreb kan blive startet af fx. et image-tag der på vegne af brugeren laver en get-forespørgsel mod det sårbare site eller det kan være en knap på en form der laver en post-forespørgsel.
Angrebseksempel
1. Ofret er logget ind på sikkerbank.dk
2. Ofret skifter over til facebook
3. På facebook modtages en statusbesked med en knap i, der står at det er en personlighedstest
4. Knappen udfører i virkeligheden en post til sikkerbank.dk der overfører et beløb til angribers konto:
<form method=post action=https://sikkerbank.dk/overfør?beløb=10000&til-konto=12341234> <input type=submit value="Start personlighedstest" /> </form>
Undgå angreb
Forsvaret går i sin enkelthed ud på at tilføje en token – en streng som en angriber ikke kan få fat i. Tokenen tilføjes til alle følsomme forespørgsler og skal være verificerbar af serveren.
Indholdet af token kan være helt tilfældigt (og gemmes som sessions-data eller i en cookie) eller en hash-genereret ud fra fx. sessionid eller ip-adresse. Ydermere kan destinations-adressen evt. indgå i den hashede værdi – dermed vil tokens være unikke pr. kald.
Værdien af token sendes så med på requests ved at tilføje den som parameter https://sikkerbank.dk/...?token=4A3d3e3 eller ved at lade den indgå i en form som en skjult værdi:
<input type=hidden name=token value=4A3d3e3 />
Hvis serversiden konkluderer at tokens ikke stemmer overens kastes en passende fejl – fx. 403 forbidden.
ASPNET MVC har en automatisk anti-CSRF mekanisme der kan aktiveres ved at indsætte en token i Razor-koden:
@Html.AntiForgeryToken()
Samt dekorere destinations-action-metoden med en attribut:
[ValidateAntiForgeryToken]
public ActionResult Login(LoginModel model) { /* ... */ }
CSRF er ikke svært at undgå. Mange web-frameworks indeholder allerede mekanismer til forhindring af angreb – det handler i de fleste tilfælde blot om at aktivere dem. Hvis ellers ens site er fri af andre sikkerhedshuller som kan røbe ens token-værdier, kan angreb forhindres ved blot at sammenligne en værdi fra hver forespørgsel med en værdi som tredjepart ikke kan få fat i.