CSRF ( engelsk cross-site request forgery - "cross-site request forgery", også kendt som XSRF) er en type angreb på besøgende på webstedet , der bruger manglerne i HTTP-protokollen . Hvis et offer besøger et websted, der er oprettet af en angriber, sendes en anmodning i hemmelighed på vegne af offeret til en anden server (for eksempel til en betalingssystemserver), der udfører en form for ondsindet handling (f.eks. overfører penge til en angribers konto). For at udføre dette angreb skal offeret være autentificeret på den server, som anmodningen sendes til, og denne anmodning må ikke kræve nogen bekræftelse fra brugeren , som ikke kan ignoreres eller forfalskes af det angribende script .
Denne type angreb, i modsætning til populær misforståelse, dukkede op for ganske lang tid siden: De første teoretiske overvejelser dukkede op i 1988 [1] , og de første sårbarheder blev opdaget i 2000 . Og selve begrebet blev introduceret af Peter Watkins i 2001 .
Hovedanvendelsen af CSRF er at tvinge udførelsen af enhver handling på et sårbart websted på vegne af offeret ( ændring af adgangskode , hemmeligt spørgsmål til gendannelse af adgangskode, mail, tilføjelse af en administrator osv.). Det er også muligt at udnytte reflekteret XSS fundet på en anden server ved hjælp af CSRF .
Angrebet udføres ved at placere et link eller et script på en webside, der forsøger at få adgang til et websted, hvor den angrebne bruger er kendt (eller formodentlig) allerede er godkendt. For eksempel kan brugeren Alice gennemse et forum, hvor en anden bruger, Bob , har sendt en besked. Lad Bob oprette et <img>-tag , hvor han specificerede URL'en som kilden til billedet , når han klikker på det, udføres en handling på webstedet for Alice's bank, for eksempel:
Bob: Hej Alice! Se hvor sød denne kat er: <img src="http://bank.example.com/?account=Alice&amount=1000000&for=Bob">Hvis Alice's bank gemmer Alice's autentificeringsoplysninger i en cookie , og hvis cookien endnu ikke er udløbet, vil Alice's browser , når du forsøger at downloade billedet, sende en cookie i anmodningen om at overføre penge til Bobs konto, som vil bekræfte Alice's autentificering. Således vil transaktionen blive gennemført med succes, selvom bekræftelsen vil ske uden Alices viden.
Alle anmodninger, der ændrer data på serveren, samt anmodninger, der returnerer personlige eller andre følsomme data, skal beskyttes.
Den enkleste måde at beskytte mod denne type angreb på er at kræve, at websteder kræver bekræftelse af de fleste brugerhandlinger og kontrollere HTTP_REFERER -feltet, hvis det er angivet i anmodningen. Denne metode kan dog være usikker og anbefales ikke [2] .
En anden almindelig metode til beskyttelse er en mekanisme, hvor en ekstra hemmelig unik nøgle er knyttet til hver brugersession, designet til at opfylde anmodninger. Den hemmelige nøgle skal ikke videregives i det klare, for eksempel, for POST -anmodninger, skal nøglen sendes i forespørgslens brødtekst, ikke i sideadressen. Brugerens browser sender denne nøgle som en del af parametrene for hver anmodning, og serveren kontrollerer denne nøgle, før der foretages nogen handling. Fordelen ved denne mekanisme, sammenlignet med Referer-kontrollen, er garanteret beskyttelse mod CSRF-angreb. Ulemperne er kravet om muligheden for at organisere brugersessioner, kravet om dynamisk generering af HTML-kode til webstedssider, samt behovet for at beskytte mod XSS og andre angreb, der gør det muligt for en angriber at opnå en unik nøgle.
HTTP/1.1-protokolspecifikationen [3] definerer sikre anmodningsmetoder såsom GET, HEAD, som ikke skal ændre data på serveren. For sådanne anmodninger er der ikke behov for at anvende CSRF-beskyttelse, så længe serveren er i overensstemmelse med specifikationen.
Du vil måske spille det sikkert og tilføje en nøgle til hver anmodning, men husk, at HTTP/1.1-specifikationen [3] tillader tilstedeværelsen af et organ for enhver anmodning, men for nogle anmodningsmetoder (GET, HEAD, DELETE) semantikken i forespørgselslegemet er ikke defineret og bør ignoreres. Derfor kan nøglen kun sendes i selve URL'en eller i HTTP-anmodningsheaderen. Du skal beskytte brugeren mod utilsigtet at distribuere nøglen som en del af en URL, f.eks. i et forum, hvor nøglen kan gøres tilgængelig for en hacker. Derfor bør anmodninger med en nøgle i URL'en ikke bruges som den adresse, man skal gå til, dvs. undgå at gå til en sådan adresse ved hjælp af klientscript, serveromdirigering, formularhandling, hyperlink på siden osv. for at skjule nøglen inkluderet i URL'en. De kan kun bruges som interne anmodninger af et script, der bruger XMLHttpRequest eller en wrapper såsom AJAX .
Det er vigtigt, at nøglen (CSRF-token) muligvis ikke er beregnet til en specifik anmodning eller formular, men til alle brugeranmodninger generelt. Derfor er det nok at lække et CSRF-token fra en URL, der udfører en simpel handling eller slet ingen handling, så enhver handling, ikke kun den, som den nu kendte URL er knyttet til, mister beskyttelsen mod anmodningsforfalskning.
Der er en mere stiv version af den tidligere mekanisme, hvor en unik engangsnøgle er forbundet med hver handling. Denne metode er sværere at implementere og ressourcekrævende. Metoden bruges af nogle sider og portaler, såsom Livejournal , Rambler osv. For 2016 var der ingen information om fordelen ved en mere rigid mulighed sammenlignet med muligheden, der bruger en enkelt hemmelig nøgle til hver session [4] .