CSRF-token

Synchronizer token-mønstret er den tilstandsfulde form: serveren genererer en stor, uforudsigelig værdi med en kryptografisk sikker tilfældighedsgenerator, gemmer den i sessionen på serversiden og indlejrer den i hver formular som skjult felt eller gør den tilgængelig for JavaScript via et meta-tag. Ved hver usikker forespørgsel (POST, PUT, PATCH, DELETE) sammenligner serveren den indsendte værdi med den gemte med en sammenligning i konstant tid og afviser forespørgslen, hvis værdien mangler eller ikke passer. Tokens pr. forespørgsel forkorter det tidsrum, hvor et lækket token kan bruges, og OWASP vurderer dem som mere sikre, men de ødelægger tilbageknappen og flere åbne faner, så tokens pr. session er det almindelige valg.

Tilstandsløse applikationer bruger double-submit-cookie-mønstret: tokenet sendes både som cookie og som parameter eller header, og serveren tjekker, at de to er ens. Den naive udgave er svag, fordi en angriber, der kan skrive cookies til domænet, fx fra et kompromitteret eller sårbart subdomæne eller via man-in-the-middle på ukrypteret HTTP, kan plante et matchende par. OWASP anbefaler derfor den signerede variant, hvor tokenet er en HMAC med en hemmelig servernøgle over en sessionsbundet værdi, der skifter ved hvert login, og en tilfældig værdi, så en plantet cookie ikke består verifikationen. Cookie-præfikser som __Host- forhindrer desuden subdomæner i at overskrive cookien.

Hvor tokenet sendes, har betydning. Det må aldrig stå i en URL, da URL'er lækker via Referer-headers, logs og browserhistorik. Single page-applikationer læser det typisk fra en cookie eller et endpoint og sender det i en brugerdefineret header som X-CSRF-Token eller X-XSRF-TOKEN (den konvention, Angulars HttpClient bruger). Frameworks maskerer tokenet ved hver rendering, hvor det XOR'es med en ny tilfældig værdi, som Django og Rails gør, så værdien i et komprimeret HTTPS-svar ikke kan genskabes via en længdebaseret sidekanal af BREACH-typen.

Et CSRF-token er ikke en autentificeringshemmelighed og beskytter ikke mod XSS: ethvert script, der kører i samme origin, kan læse det fra DOM'en. Det gør heller intet for forespørgsler, der autentificeres med et bearer token i Authorization-headeren, fordi browsere ikke sender den med automatisk, så API'er uden cookies har som regel ikke brug for et. At generere et nyt token, når brugeren logger ind, forhindrer, at et token hentet før autentificering genbruges på samme måde som ved session fixation.