{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"security/cross-site-request-forgery","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/security/cross-site-request-forgery/","da":"https://cmaintz.github.io/tech-atlas/da/terms/security/cross-site-request-forgery/"},"term":{"en":"Cross-site request forgery (CSRF)","da":"Cross-site request forgery (CSRF)"},"aka":{"en":["CSRF","XSRF","session riding"],"da":["CSRF","XSRF"]},"domain":["security"],"cluster":"application-security","layer":"application","status":"current","era":2001,"summary":{"en":"An attack where a harmful page makes a user's browser send a request to a site they are logged in to, which acts as if they asked.","da":"Et angreb, hvor en ondsindet side får brugerens browser til at sende en forespørgsel til et site, som tror, brugeren selv bad om den."},"body":{"formal":{"en":"A flaw in a web application that carries out a state-changing request just because it arrives with the user's cookie; since the web browser attaches that cookie by itself, a page on another site can trigger the request without the user knowing.","da":"En fejl i en webapplikation, der udfører en ændring alene fordi forespørgslen kommer med brugerens cookie; da webbrowseren selv sender cookien med, kan en side på et andet site udløse forespørgslen, uden at brugeren opdager det."},"plain":{"en":"Like someone slipping a signed order form into your post - the shop sees your signature and fills the order, never asking whether you meant to send it.","da":"Som når nogen lægger en underskrevet bestillingsseddel ind mellem dine breve - butikken ser din underskrift og sender varen uden at spørge, om det var dig, der ville bestille."},"inPractice":{"en":"A case officer in a municipality is logged in to the case system and opens a link in a mail; the page quietly submits a hidden form that changes the payout account on a citizen's case, and the system accepts it because the login cookie came along.","da":"En sagsbehandler i en kommune er logget ind i sagssystemet og åbner et link i en mail; siden sender i al stilhed en skjult formular, der ændrer udbetalingskontoen på en borgers sag, og systemet godtager den, fordi cookien fra login fulgte med."},"whyItMatters":{"en":"The attacker never needs the password or even sees the response; a single visit to the wrong page can change an email address or password, or move money, in the user's name.","da":"Angriberen behøver hverken adgangskoden eller at se svaret; ét besøg på den forkerte side kan ændre en e-mailadresse eller en adgangskode eller flytte penge i brugerens navn."}},"deepDive":{"en":"CSRF exists because browsers historically attached ambient credentials (cookies, HTTP Basic credentials, client certificates) to every request for a site, whatever page initiated it. A cross-origin page can cause GET requests with an img or link, and POST requests with an auto-submitted form using the three \"simple\" content types (application/x-www-form-urlencoded, multipart/form-data, text/plain) without a CORS preflight. The same-origin policy blocks the attacker from reading the response, but a state change on the server has already happened. The attack is therefore blind and one-way; it only works when the attacker can predict every parameter of the request.\n\nVariants widen the scope. Login CSRF logs the victim into the attacker's account so later activity (searches, stored card details) is recorded where the attacker can see it. JSON endpoints are vulnerable if the server parses a text/plain body as JSON or does not check Content-Type. State-changing GET handlers are exploitable from any image tag. Routers and other devices on the local network have been attacked through CSRF from a web page, since the browser sits inside the network. An XSS flaw on the same site defeats every CSRF defence, because script running in the origin can read tokens and send same-origin requests.\n\nThe OWASP prevention cheat sheet treats a synchronizer token or a signed double-submit cookie as the classic primary defence and, for modern browsers, also accepts Fetch Metadata checks as a primary control: reject unsafe methods such as POST when Sec-Fetch-Site is cross-site. Custom request headers suit API-only endpoints, since a cross-origin page cannot set one without a preflight that the server can refuse. Defence in depth adds SameSite cookies and verification of the Origin header. Chromium has treated cookies without a SameSite attribute as Lax since 2020, which blocks most cross-site POSTs but still allows top-level GET navigations, and Lax does nothing against same-site attacks from a sibling subdomain.\n\nCSRF was in the OWASP Top 10 as its own category in 2007, 2010 and 2013 and was dropped in 2017, largely because frameworks such as Django, Rails, ASP.NET Core and Spring Security enable token protection by default; it is catalogued as CWE-352. The remaining failures are usually custom endpoints that opt out of framework protection, token checks applied only to POST, and APIs that switched from bearer headers to cookies without adding a defence.","da":"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.\n\nVarianter 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.\n\nOWASP'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.\n\nCSRF 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."},"edges":[{"type":"requires","to":"cs/web-application","confidence":"high","strength":"normal"},{"type":"requires","to":"cs/cookie","confidence":"high","strength":"normal"},{"type":"contrasts-with","to":"security/cross-site-scripting","why":{"en":"XSS runs the attacker's script inside the trusted site; CSRF runs nothing there and only borrows the user's login to send one request from outside.","da":"XSS kører angriberens script inde på det betroede site; CSRF kører intet dér og låner kun brugerens login til at sende én forespørgsel udefra."},"confidence":"high","strength":"primary"},{"type":"exploits","to":"cs/session","why":{"en":"The site trusts every request that carries the session cookie, and the browser attaches it even when another site started the request.","da":"Sitet stoler på enhver forespørgsel med sessionscookien, og browseren sender den med, selv når et andet site startede forespørgslen."},"confidence":"high","strength":"primary"},{"type":"used-with","to":"cs/same-origin-policy","why":{"en":"The browser rule does not stop the forged request from being sent, but it keeps the attacker's page from reading a CSRF token, which is what lets that defence work.","da":"Browserreglen forhindrer ikke, at den forfalskede forespørgsel bliver sendt, men den forhindrer angriberens side i at læse et CSRF-token, og det er netop det, der får det forsvar til at virke."},"confidence":"high","strength":"minor"}],"depth":7,"sources":[{"title":"OWASP - Cross Site Request Forgery (CSRF)","url":"https://owasp.org/www-community/attacks/csrf","tier":"reference","publisher":"OWASP"},{"title":"OWASP Cheat Sheet Series - Cross-Site Request Forgery Prevention","url":"https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html","tier":"reference","publisher":"OWASP"}],"draft":true}