Drepte SameSite-informasjonskapsler CSRF?

Reduserte den betydelig, men eliminerte ikke. SameSite=Lax (den moderne standarden) tillater informasjonskapsler på tvers av nettsteder på toppnivånavigering. SameSite=Streng forhindrer det også, men bryter legitime flyter. CSRF-tokens er fortsatt det anbefalte forsvaret; SameSite er et komplementært lag.

Hvordan er CSRF forskjellig fra XSS?

XSS injiserer ondsinnet kode i det pålitelige nettstedet, og kjører med sine privilegier. CSRF lurer nettleseren til å sende en forespørsel til det pålitelige nettstedet uten å injisere noe. XSS kan gjøre alt CSRF kan gjøre, og mer. De er forskjellige angrepsmekanismer.

Kan jeg teste for CSRF i min egen applikasjon?

Ja. Prøv å sende inn skjemaer med token fjernet eller endret; hvis handlingen går gjennom, har du CSRF. Test i Chrome med SameSite-håndhevelse; noen eldre rammeverk har CSRF-tokens som faktisk ikke er verifisert. Manuell gjennomgang er enkel.

Trenger enkeltsideapper CSRF-beskyttelse?

Hvis de autentiserer via informasjonskapsler, ja. Hvis de autentiserer via Bearer-tokens som er lagret på klientsiden (localStorage), er de mindre CSRF-sårbare, men mer XSS-eksponerte. Begge angrepsflatene betyr noe; velg autentiseringsmekanismen med begge i tankene.

Er CSRF fortsatt i OWASP Topp 10?

Den falt ut av topp 10 i 2021 på grunn av utbredt reduksjon på rammenivå og standardinnstillinger for SameSite-informasjonskapsler. Det er fortsatt på OWASP-listen over betydelige sårbarheter; prevalensen har falt, ikke den underliggende mekanismen.

CSRF forklart: Når et nettsted lurer nettleseren din til å handle på dine vegne

Forfalskning av forespørsler på tvers av nettsteder er sårbarheten der en ondsinnet side får nettleseren din til å sende inn en forespørsel til et nettsted der du er logget på – ved å bruke legitimasjonen din og utføre handlinger du ikke har godkjent. SameSite-informasjonskapsler har lukket det meste av den historiske angrepsoverflaten, men den underliggende klassen er fortsatt viktig uansett hvor informasjonskapsler autentiserer tilstandsendre operasjoner.

Hele artikkelen er gitt på engelsk nedenfor.

Cross-Site Request Forgery (CSRF, noen ganger kalt XSRF eller "sea-surf") utnytter et nettsteds tillit til brukerens nettleser. Angriperen kan ikke se informasjonskapslene dine, men nettleseren sender dem automatisk med hver forespørsel til opprinnelsen de tilhører. Hvis angriperen kan utløse nettleseren din til å sende en forespørsel til et nettsted der du er logget inn, ser det nettstedet en autentisert forespørsel – selv om angriperen startet den.

Det klassiske angrepet

Se for deg en bank som behandler overføringer via en enkel GET-forespørsel: https://bank.example/transfer?to=Bob&amount=1000. Du er logget inn i banken. En angriper sender deg en lenke på e-post eller er vert for en side med en bildekode som peker til https://bank.example/transfer?to=Attacker&amount=10000. Nettleseren din laster bildet; banken ser en autentisert forespørsel fra økten din; overføringen går gjennom.

TDet spesifikke eksemplet er stort sett historisk – banker behandler ikke overføringer via GET lenger – men mønsteret er generelt. Enhver tilstandsendringsforespørsel som autentiseres utelukkende via øktinformasjonskapsler er potensielt CSRF-sårbare.

Hva gjør CSRF mulig

Ttre grunnlag:

Cookies sendes automatisk. ber om tillatelse; informasjonskapsler tilhører opprinnelsen og reiser med hver forespørsel til den opprinnelsen, uavhengig av hvor forespørselen ble initiert.
HTML kan utløse forespørsler med kryssopprinnelse. Bildetagger, skjemainnsendinger, skripttagger og forskjellige andre elementer kan alle rettes mot en hvilken som helst URL.

Standardforsvaret

CSRF-tokens (synkroniseringstokener). Serveren inkluderer et tilfeldig token i alle former. Innleveringer må inneholde token. Angriperens ondsinnede side kan ikke lese tokenet (policy for samme opprinnelse), så falske forespørsler mislykkes. Moderne nettrammeverk genererer og verifiserer tokens automatisk.
SameSite cookies. Informasjonskapsler merket SameSite=Lax (standard i moderne nettlesere siden 2020) sendes ikke på forespørsler på tvers av nettsteder bortsett fra toppnivånavigering. SameSite=Streng er enda strammere. Dette er den største enkeltendringen som reduserte CSRF-risikoen de siste fem årene.
Origin og Referer header validation. Servere kan sjekke at Origin header samsvarer med forventet opprinnelse. Forespørsler på tvers av nettsteder har en annen opprinnelse, som tillater avvisning.
Double-submit cookie. Server setter en verdi i både en informasjonskapsel og en separat forespørselsparameter; verifikatoren sjekker at de stemmer overens. Fungerer uten sesjonsstatus på serversiden.
Re-autentisering for sensitive handlinger. Passordbekreftelse, MFA-utfordring eller trinnvis autentisering på operasjoner med høy verdi. Beseirer CSRF og flere andre angrepsklasser samtidig.

The SameSite-revolusjon av informasjonskapsler

Før 2020 hadde hver forespørsel på tvers av nettsteder destinasjonsnettstedets informasjonskapsler – inkludert tilstandsendre forespørsler fra ondsinnede sider. SameSite=Lax gjorde informasjonskapsler på tvers av nettsteder til unntaket i stedet for regelen. Store nettlesere brukte Lax som standard i 2020-2021, og virkningen var dramatisk: de fleste tilfeldige CSRF-sårbarheter ble ikke-utnyttbare over natten.

Fangsten: SameSite=Lax tillater fortsatt informasjonskapsler på toppnivånavigasjoner (viderekoblinger på hele siden). Statusendrende operasjoner som utløses ved å klikke på en lenke, kan fortsatt inneholde informasjonskapsler. Forsvaret er bra, men ikke komplett.

SameSite=Strict forhindrer dette helt. Avveiningen: det bryter påloggingsflyter som avhenger av navigering på tvers av nettsteder (Single Sign-On, post-OAuth omdirigeringer). De fleste større nettsteder bruker Lax som standard og Strict kun på de mest sensitive informasjonskapslene.

CSRF og APIer

Moderne APIer autentiserer ofte via autorisasjonshoder (bærer-tokens) i stedet for informasjonskapsler. CSRF gjelder ikke fordi nettleseren ikke automatisk inkluderer vilkårlige overskrifter på kryssopprinnelsesforespørsler. CSRF-problemet tilhører i stor grad informasjonskapselautentiserte systemer.

Men APIer som blander informasjonskapsler for noen flyter og tokens for andre kan ha subtile CSRF-overflater. Bruk den ene eller den andre konsekvent.

CSRF og CORS

CORS (Cross-Origin Resource Sharing) definerer når en nettleser lar en kryssopprinnelsesforespørsel leses av JavaScript. CSRF handler om hvorvidt forespørselen i det hele tatt er sent, med informasjonskapsler. De er relaterte, men forskjellige:

CSRF hindrer den ondsinnede siden fra å forårsake forespørselen
CORS hindrer den ondsinnede siden i å lese svaret

A CSRF-angrepet trenger ikke å lese svaret – det trenger bare at serveren utfører handlingen. Nettleseren avfyrer pliktoppfyllende forespørselen og får et svar; den skadelige siden ser den kanskje ikke, men skaden er gjort. CORS fikser ikke CSRF.

Kjente CSRF-hendelser

Netflix-kømanipulasjon (2006). Forskere fant ut at lagde IMG-tagger kunne legge til filmer i Netflix-køen din uten din involvering. Reparasjonen var de første CSRF-tokenene i utstrakt bruk.
YouTube-kontoovertakelsesvarianter på slutten av 2000-tallet.
GitHub-sletting av depot via CS2RF (fikset i 20 raskt).
Tallrike WordPress-plugin CSRF-sårbarheter rapporteres hvert år; plugin-økosystemet produserer dem fortsatt i stor skala.

For utviklere i 2026

Bruk et rammeverk med innebygd CSRF-beskyttelse (Django, Rails, Spring, Laravel har det alle)
Set SameSite=Lakse (eller strenge) på øktinformasjonskapsler
For APIer, bruk bærer-tokens i stedet for informasjonskapsler når det er mulig
Krev ny autentisering for operasjoner med høy innsats
Doit re-autentization for high-stakes-operasjoner
Don headers

For brukere

Du kan ikke forsvare deg direkte mot CSRF – det er en feil på serversiden. De moderne nettleserstandardene (SameSite=Lax) hjelper betydelig, men du er avhengig av at hvert nettsted du logger på har implementert beskyttelse. Vær pålogget bare så lenge du trenger; logge av sensitive kontoer når de ikke er i bruk; og stol på moderne store nettsteder – de har alle jobbet med CSRF i sine trusselmodeller.

Ofte stilte spørsmål

Drepte SameSite-informasjonskapsler CSRF?: Reduserte den betydelig, men eliminerte ikke. SameSite=Lax (den moderne standarden) tillater informasjonskapsler på tvers av nettsteder på toppnivånavigering. SameSite=Streng forhindrer det også, men bryter legitime flyter. CSRF-tokens er fortsatt det anbefalte forsvaret; SameSite er et komplementært lag.
Hvordan er CSRF forskjellig fra XSS?: XSS injiserer ondsinnet kode i det pålitelige nettstedet, og kjører med sine privilegier. CSRF lurer nettleseren til å sende en forespørsel til det pålitelige nettstedet uten å injisere noe. XSS kan gjøre alt CSRF kan gjøre, og mer. De er forskjellige angrepsmekanismer.
Kan jeg teste for CSRF i min egen applikasjon?: Ja. Prøv å sende inn skjemaer med token fjernet eller endret; hvis handlingen går gjennom, har du CSRF. Test i Chrome med SameSite-håndhevelse; noen eldre rammeverk har CSRF-tokens som faktisk ikke er verifisert. Manuell gjennomgang er enkel.
Trenger enkeltsideapper CSRF-beskyttelse?: Hvis de autentiserer via informasjonskapsler, ja. Hvis de autentiserer via Bearer-tokens som er lagret på klientsiden (localStorage), er de mindre CSRF-sårbare, men mer XSS-eksponerte. Begge angrepsflatene betyr noe; velg autentiseringsmekanismen med begge i tankene.
Er CSRF fortsatt i OWASP Topp 10?: Den falt ut av topp 10 i 2021 på grunn av utbredt reduksjon på rammenivå og standardinnstillinger for SameSite-informasjonskapsler. Det er fortsatt på OWASP-listen over betydelige sårbarheter; prevalensen har falt, ikke den underliggende mekanismen.