Cross-site request forgery (CSRF)

CSRF findes, fordi browsere historisk har sendt ambiente legitimationsoplysninger (cookies, HTTP Basic-oplysninger, klientcertifikater) med hver forespørgsel til et site, uanset hvilken side der startede den. En side fra en anden origin kan udløse GET-forespørgsler med et img-tag eller et link og POST-forespørgsler med en formular, der sendes automatisk, med de tre "simple" content types (application/x-www-form-urlencoded, multipart/form-data, text/plain) uden CORS-preflight. Same-origin policy forhindrer angriberen i at læse svaret, men tilstandsændringen på serveren er allerede sket. Angrebet er derfor blindt og envejs; det virker kun, når angriberen kan forudsige alle forespørgslens parametre.

Varianter udvider feltet. Login-CSRF logger offeret ind på angriberens konto, så senere aktivitet (søgninger, gemte kortoplysninger) registreres dér, hvor angriberen kan se den. JSON-endpoints er sårbare, hvis serveren tolker en text/plain-body som JSON eller ikke tjekker Content-Type. Tilstandsændrende GET-handlere kan udnyttes fra ethvert billedtag. Routere og andre enheder på det lokale netværk er blevet angrebet via CSRF fra en webside, fordi browseren står inde på netværket. En XSS-fejl på samme site slår alle CSRF-forsvar ud, fordi script, der kører i origin'en, kan læse tokens og sende forespørgsler fra samme origin.

OWASP's cheat sheet om forebyggelse ser et synchronizer token eller en signeret double-submit-cookie som det klassiske primære forsvar og godtager for moderne browsere også Fetch Metadata-tjek som primær kontrol: afvis usikre metoder som POST, når Sec-Fetch-Site er cross-site. Brugerdefinerede request headers passer til rene API-endpoints, fordi en side fra en anden origin ikke kan sætte en sådan header uden en preflight, som serveren kan afvise. Som ekstra lag bruges SameSite-cookies og kontrol af Origin-headeren. Chromium har siden 2020 behandlet cookies uden SameSite-attribut som Lax, hvilket blokerer de fleste cross-site POST-kald, men stadig tillader GET-navigation på topniveau, og Lax hjælper intet mod angreb fra et søsterdomæne på samme site.

CSRF var en selvstændig kategori i OWASP Top 10 i 2007, 2010 og 2013 og røg ud i 2017, primært fordi frameworks som Django, Rails, ASP.NET Core og Spring Security slår tokenbeskyttelse til som standard; svagheden er katalogiseret som CWE-352. De fejl, der er tilbage, er typisk hjemmelavede endpoints, der fravælger frameworkets beskyttelse, tokentjek, der kun gælder POST, og API'er, der er skiftet fra bearer-headers til cookies uden at tilføje et forsvar.