Virkning
Cross-Site Request Forgery (CSRF) lar en angriper lure et offers nettleser til å utføre uønskede handlinger på et annet nettsted der offeret for øyeblikket er autentisert. Fordi nettlesere automatisk inkluderer omgivelseslegitimasjon som informasjonskapsler i forespørsler, kan en angriper forfalske tilstandsendre operasjoner – som å endre passord, slette data eller starte transaksjoner – uten brukerens viten.
Grunnårsak
Den grunnleggende årsaken til CSRF er nettleserens standardoppførsel for å sende informasjonskapsler knyttet til et domene når en forespørsel sendes til det domenet, uavhengig av forespørselens opprinnelse [S1]. Uten spesifikk validering av at en forespørsel ble utløst med hensikt fra applikasjonens eget brukergrensesnitt, kan ikke serveren skille mellom en legitim brukerhandling og en forfalsket handling.
Django CSRF-beskyttelsesmekanismer
Django tilbyr et innebygd forsvarssystem for å redusere disse risikoene gjennom mellomvare og malintegrasjon [S2].
Mellomvareaktivering
django.middleware.csrf.CsrfViewMiddleware er ansvarlig for CSRF-beskyttelse og er vanligvis aktivert som standard [S2]. Den må plasseres før noen visningsmellomvare som antar at CSRF-angrep allerede er håndtert [S2].
Malimplementering
For alle interne POST-skjemaer må utviklere inkludere {% csrf_token %}-taggen inne i <form>-elementet [S2]. Dette sikrer at et unikt, hemmelig token er inkludert i forespørselen, som serveren deretter validerer mot brukerens økt.
Token-lekkasjerisiko
En kritisk implementeringsdetalj er at {% csrf_token %} aldri skal inkluderes i skjemaer som er målrettet mot eksterne nettadresser [S2]. Å gjøre det vil lekke det hemmelige CSRF-tokenet til en tredjepart, og potensielt kompromittere brukerens øktsikkerhet [S2].
Forsvar på nettlesernivå: SameSite-informasjonskapsler
Moderne nettlesere har introdusert SameSite-attributtet for Set-Cookie-headeren for å gi et lag med forsvar i dybden [S1].
- Streng: Informasjonskapselen sendes kun i en førstepartskontekst, noe som betyr at nettstedet i URL-linjen samsvarer med informasjonskapselens domene [S1].
- Laks: Informasjonskapselen sendes ikke på underforespørsler på tvers av nettsteder (som bilder eller rammer), men sendes når en bruker navigerer til opprinnelsesnettstedet, for eksempel ved å følge en standardlenke [S1].
Hvordan FixVibe tester for det
FixVibe inkluderer nå CSRF-beskyttelse som en gated aktiv sjekk. Etter domeneverifisering inspiserer active.csrf-protection oppdagede skjemaer som endrer tilstand, sjekker for CSRF-token-formede innganger og SameSite-informasjonskapselsignaler, og forsøker deretter en innsending med lav innvirkning forfalsket opprinnelse og rapporterer bare når serveren godtar det. Cookie-sjekker flagger også svake SameSite-attributter som reduserer CSRF-forsvaret i dybden.