När jag arbetar med CSRF försöker jag börja i den faktiska tillgången, datan och förändringen som ska skyddas. CSRF utnyttjar att webbläsaren automatiskt skickar en giltig session till rätt webbplats även när användaren startade begäran från en annan origin.
CSRF i praktiken
Första byggstenen: Anti-CSRF-token binder en state-changing request till den legitima applikationsvyn. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
En annan viktig del: SameSite-cookies reducerar vissa cross-site requests. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det tekniska ankaret: Origin eller Referer kan användas som ytterligare kontroll för känsliga endpoints. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det som ofta avgör kvaliteten: GET ska inte ändra serverstate. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Från nuläge till verifierad kontroll
- Identifiera alla state-changing routes.
- Använd ramverkets CSRF-skydd konsekvent.
- Sätt cookie-attribut enligt applikationens flöden.
- Kontrollera origin där det är lämpligt.
- Testa en cross-site form eller fetch från separat origin.
För CSRF håller jag därför införandet i små steg. Då går det att skilja ett säkerhetsproblem från ett rent driftfel och att rulla tillbaka just den ändring som gav ett oväntat resultat.
Exempel från ett driftperspektiv
En användare kan vara korrekt inloggad och ändå luras att skicka en betalnings- eller profiländring. Testet ska därför bevisa att servern kräver mer än bara den automatiskt medskickade sessionscookien.
Fallgropar jag försöker undvika
- Att skydda bara formulär men glömma JSON-endpoints med cookie-session.
- Att använda GET för delete eller annan förändring.
- Att sätta SameSite=None utan att förstå varför.
Kontrollpunkter
För CSRF vill jag avsluta med mätbara efterkontroller i stället för att nöja mig med att en statusruta visar ”enabled”. De viktigaste kontrollerna här är:
- Legitim request med token lyckas.
- Cross-site request utan token nekas.
- Read-only GET ändrar inte data.
Ett negativt test hör också till CSRF: den väg, identitet eller operation som inte ska vara tillåten ska misslyckas på ett förutsägbart sätt. Då kan nästa tekniker upprepa kontrollen och förstå både avsikten och gränsen.
Slutsats
CSRF – varför en giltig session inte betyder att en begäran är legitim handlar därför inte om att samla fler säkerhetsinställningar. Det handlar om att minska en konkret risk med en kontroll som har tydligt scope, tydlig ägare och ett verifierbart resultat. När före-läge, förändring och eftertest dokumenteras blir säkerhetsarbetet både säkrare och lättare att förvalta.