Hvad er CSRF og hvordan forhindrer du det?

Question

Accepted Answer

**CSRF (Cross-Site Request Forgery)** snyder en indlogget brugers browser til at lave **uønskede anmodninger** til et sted, hvor de er autentificeret — hvilket udfører handlinger (overførsler, ændringer) uden deres samtykke, udnyttende browserens automatiske afsendelse af legitimationsoplysninger/cookies. ## Hvordan CSRF fungerer ```text The attack exploits that browsers AUTO-SEND cookies (incl. session cookies) with requests: 1. a user is LOGGED IN to a site (has a session cookie) 2. the user visits a MALICIOUS page (or clicks a crafted link) 3. that page makes a request to the target site (e.g. a hidden form auto-submitting) 4. the browser AUTOMATICALLY includes the user's session cookie → the site thinks it's a legitimate request from the user → performs the action (transfer money, change email) → the user unknowingly performs an action they didn't intend. ``` ```html ``` ## Forebyggelse ```text ✓ CSRF TOKENS → a unique, unpredictable token per session/form that the server verifies; the attacker's site can't know it → the forged request fails (the primary defense) ✓ SameSite COOKIES → SameSite=Lax/Strict → cookies NOT sent on cross-site requests → blocks CSRF (now a strong, default-ish browser defense) ✓ Check Origin/Referer headers; require re-authentication for sensitive actions ✓ Don't use GET for state-changing actions (use POST/PUT/DELETE properly) → Frameworks often provide CSRF protection built in — enable/use it. ``` ## Hvorfor det betyder noget At forstå CSRF og hvordan man forhindrer det er værdifuldt, fordi det er en **almindelig webs sårbarhed**, der udnytter, hvordan browsere fungerer, hvilket gør det muligt for angribere at udføre handlinger som autentificerede brugere, så det er vigtig sikkerhedsviden for webudviklere. At forstå **hvordan CSRF fungerer** — udnyttelse af, at browsere **automatisk sender cookies** (herunder sessionscookies) med anmodninger, så en ondsindet side kan udløse en anmodning til et sted, hvor brugeren er indlogget, og browseren inkluderer sessionscookien, hvilket får siden til at behandle den forfalskede anmodning som legitim og udføre handlingen (overførsler, kontoændringer) uden brugerens samtykke — er nødvendigt for at forstå dette subtile men farligt angreb. CSRF er farligt, fordi det kan udføre sensitive handlinger som offeret uden deres viden, og det er en almindelig webs sårbarhed. At forstå **forebyggelsen** er vigtig: **CSRF-tokens** (et unikt, uforudsigeligt token per session/formular, som serveren verificerer — angribers side kan ikke kende det, så forfalskede anmodninger mislykkes; det primære traditionelle forsvar), **SameSite-cookies** (indstilling af SameSite=Lax/Strict, så cookies ikke sendes på cross-site-anmodninger, nu et stærkt browser-niveau forsvar, som i stigende grad er standard), kontrol af Origin/Referer-headere, krævet genautentificering for sensitive handlinger, og ikke brug af GET til tilstandsændring af operationer. At forstå, at **frameworks ofte giver indbygget CSRF-beskyttelse** (som bør være aktiveret og bruges) er praktisk vigtig. Kombinationen af CSRF-tokens og SameSite-cookies giver robust beskyttelse. Da CSRF er en almindelig webs sårbarhed, der udnytter browseradfærd til at udføre uønskede handlinger som autentificerede brugere, og da det at forstå, hvordan det fungerer og hvordan man forhindrer det (CSRF-tokens, SameSite-cookies, framework-beskyttelse) er vigtigt for webudviklere, er forståelsen af CSRF og dets forebyggelse værdifuld, praktisk relevant sikkerhedsviden — en vigtig webs sårbarhed at forstå og forsvare sig imod, hvor forsvarene (CSRF-tokens og SameSite-cookies) er vigtig viden til beskyttelse af brugere mod at blive narret til uønskede handlinger, en bemærkelsesværdig angrebsklasse for enhver webapplikation med autentificeret tilstandsændring af operationer.